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):
>
> Hi Deri,
>
[...]
>>> 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?

Hi Branden,

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. 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, 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.

(b) is not correct, \[uXXXX] is always acceptable in bookmarks, I don't need
to look at fonts to find out the unicode.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?67680>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature

Reply via email to