[bug #66133] [mom] pdfmom: missing 8-bit characters with and without '-K utf8'

Follow-up Comment #1, bug #66133 (group groff): Hi Bjarni, I assume you are using the latest git which includes Peter's changes, with them I can't duplicate the issue. Of course, feeding a UTF-8 encoded document to groff without using preconv is likely to cause issues, because groff reads everyth

[bug #66133] [mom] pdfmom: missing 8-bit characters with and without '-K utf8'

Update of bug #66133 (group groff): Status:None => Unreproducible ___ Follow-up Comment #2: [comment #0 original submission:] > File: contrib/mom/examples/mon_premiere.doc.mom Correct filenam

[bug #66133] [mom] pdfmom: missing 8-bit characters with and without '-K utf8'

Follow-up Comment #3, bug #66133 (group groff): [comment #2 comment #2:] > Where the TOC shows up, or whether it shows up at all, is a > function of your PDF viewer, not of anything under groff's control. Clarification: one of the pages of the document is a TOC ("Table des matières"); Bjarni and

[bug #66133] [mom] pdfmom: missing 8-bit characters with and without '-K utf8'

Follow-up Comment #4, bug #66133 (group groff): I've nothing further to add. I think we can close this. ___ Reply to this item at: ___ Message sent via

[bug #66133] [mom] pdfmom: missing 8-bit characters with and without '-K utf8'

Follow-up Comment #5, bug #66133 (group groff): This turned out to be a bug in 'xpdf'. "okular" has a similar page design but renders the left part of the display correctly. xpdf -v : xpdf version 3.04 Copyright 1996-2014 Glyph & Cog, LLC Copyright 2014-2021 xpopple contributors ( Debian tes

[bug #66133] [mom] pdfmom: missing 8-bit characters with and without '-K utf8'

Update of bug #66133 (group groff): Open/Closed:Open => Closed ___ Follow-up Comment #6: This shows the ouutline panel fine:- [derij@pip build (master)]$ xpdf -v xpdf version 4.05 [www.xpd

[bug #66133] xpdf doesn't render non-ASCII characters in navigation pane

Update of bug #66133 (group groff): Category: Macro package mom => General Status: Unreproducible => Invalid Assigned to:None => deri Summary: [mom]

[bug #63074] [troff] support construction of arbitrary byte sequences in device control commands

Follow-up Comment #33, bug #63074 (group groff): This more or less does it for `\X` escape sequences, without (as far as I can tell [and we _do_ have 200+ automated tests]) regressing anything. But there's much more ground to cover. See my discussion with Deri in bug #64484. commit c8332c5c1ac

[bug #66133] xpdf doesn't render non-ASCII characters in navigation pane

Follow-up Comment #8, bug #66133 (group groff): I will add that it is straightforward to determine if non-ASCII characters are correctly making it out of GNU _troff_. You use the `-Z` option to _groff_ or _nroff_ (or run _troff_ directly) and _grep_ the output for device extension (a.k.a. device

[bug #66132] [gropdf] develop a test for new gropdf image formats

Follow-up Comment #2, bug #66132 (group groff): Deri noted in bug #66114: > This may be one of those problems for which there may not be a 100% solution, and its a question of whether a less than 100% solution is worth it. You may want to look at the program pdfdiff. If we had a "gold standard" p

[bug #63827] withdraw contrib/pdfmark

Follow-up Comment #15, bug #63827 (group groff): A little detangling from _mom_(7) will be necessary. $ git grep 'gropdf-info' contrib/mom/om.tmac:. if !dpdf:href.map .tm gropdf-info:href \\*[PDF_NM2] \\*[PDF_TX] contrib/mom/om.tmac:.if '\\*[.T]'ps' .if !dpdf:href.map .tm gropdf

[bug #64683] update with respect to Unicode 15.1

Update of bug #64683 (group groff): Status:None => In Progress Assigned to:None => gbranden Summary: update with respect to Unicode 16.0 => update with respect to Unicode 15.1 __