Follow-up Comment #3, bug #67680 (group groff): Hi Deri,
At 2025-11-06T16:20:23-0500, Deri James wrote:
> Follow-up Comment #2, bug #67680 (group groff):
>
>> 1. We shouldn't still be leaving a node in the asciified diversion.
>> That `\u0000` is a killer. I **suspect**, but don't know for sure,
>> that the PDF viewer Deri's using in bug #66653 misinterprets the
>> null character as a string terminator and stops populating the
>> navigation bar. For me, _okular_, _evince_, and _xpdf_ just skip
>> over it.
>
> I am surprised at this because the grout shows:-
>
> x T pdf
> x res 72000 1 1
> x init
> p1
> x X ps:exec [/Dest /pdf:bm1 /View [/FitH -67000 u] /DEST pdfmark
> x X ps:exec [/Dest /pdf:bm1 /Title (Proof: 1 ) /Level 1 /OUT pdfmark
Ah. Yup. Your use of the Tinos font, or selection of a glyph that
maybe lacks a precomposed form in groff's Unicode<->glyph tables might
by queering the results.
Oh wait. This is _my_ example. WTF?
I agree that in this output the bookmark label is getting truncated
before gropdf gets a hold of it, let alone the PDF viewer application.
$ ./build/test-groff -k -ww -T pdf -Z ATTIC/not_equals.groff 2>/dev/null |
grep '^x X'
x X ps:exec [/Dest /pdf:bm1 /View [/FitH -67000 u] /DEST pdfmark
x X ps:exec [/Dest /pdf:bm1 /Title (Proof: 1 ) /Level 1 /OUT pdfmark
x X ps:exec [/Dest /pdf:bm2 /View [/FitH -91000 u] /DEST pdfmark
x X ps:exec [/Dest /pdf:bm2 /Title (Proof: 1 \[!=] 2) /Level 1 /OUT pdfmark
(First the "asciified" diversion is written as a bookmark, and is
truncated because of the problem at issue, and then the bookmark is
written out using the original string that never got formatted, so it's
a "pure" string [one with only "contents" and not a "node list".)
Okay, that's consistent at least. This is a reproducer that doesn't
require a person to install the Tinos font(s).
>> 2. We should throw some kind of warning if we hit a special
>> character we can't asciify (and say **why** we can't asciify it).
>
> I don't see **why** we can't asciify '!=' given it is in the glyphuni
> table:-
>
> ../../src/libs/libgroff/glyphuni.cpp: { "!=", "2260"
>
> So the proper 'textification' of the special character would be
> '\[u2260]'.
I don't see why either. This failure surprises me.
>> 3. Surely we should be prepared to handle any special character
>> defined in _groff_char_(7), except for the two undefined by Unicode
>> (`\[bs]\` and `\[ru]`)
>
> If you add the line '.fam U-T' at the top of the script you will see
> the belly-ache from gropdf about not finding unicode for '!='
> disappears.
Okay. We should see the bellyache if (a) '.fam U-T' is not inserted
even if (b) `\[!=]` gets asciified/textified as `\[u2260]`, right?
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67680>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
