Follow-up Comment #5, bug #67680 (group groff): Hi Deri,
At 2025-11-06T18:40:45-0500, Deri James wrote:
> Follow-up Comment #4, bug #67680 (group groff):
> On Thursday, 6 November 2025 21:35:48 GMT G. Branden Robinson wrote:
>> Follow-up Comment #3, bug #67680 (group groff):
>>>> 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?
>
> I know why this is true. U-TR has '!=' which has 2260 as a comment. TR
> has no '!=' so it is found in S (which does have 2260 as a comment,
> but at the point where .pdfbookmark is issued font has been switched
> back to TR). One solution is for gropdf to try a bit harder, by
> searching in any other fonts which have been loaded if not found in
> current text font.
I get the feeling that shouldn't be necessary. The contents of a device
extension command, in principle--and in this application--aren't
depending on which font is selected at the time is encountered, because
its text argument isn't being formatted _as part of the document_.
Rather, it's--from the PDF generation perspective--"font-agnostic" text
that is thrown to the rendering application's UI library for handling.
> Another 'solution', if you can persuade groff to output \[uXXXX]
> rather than the special-char name, since if you change \[!=] to
> \[u2260] in the .ds label line,
`\[u2660]`, but yes, can reproduce. I wonder if I'm going to have to
hang a flag on glyph resolution function calls. :-/
> the second pdfbookmark is correct (the first is still truncated, so I
> suspect internally, it has become \[!=] again) - and no belly-aching
> about the second bookmark either.
Yes. Solving one problem may solve the other. Or there may be two
bugs. I'll have to dig deeper.
> (b) is not correct, \[uXXXX] is always acceptable in bookmarks, I
> don't need to look at fonts to find out the unicode.
Good--that's consistent with my "shouldn't be necessary" observation
above.
I'll revisit my `::asciify()` changes and see what I can figure out.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67680>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
