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


> 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]'.

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


    _______________________________________________________

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