Follow-up Comment #35, bug #64360 (group groff): [comment #34 comment #34:] > Discussion about this issue has temporarily jumped ship to bug #67992. > Hopefully it finds its way back here, as it has fsck-wall to do with #67992's > topic.
Not for very long. It pretty much jumped back. Bug #67992 still mostly has to do with the issue I just posted to the _groff_ list about. https://lists.gnu.org/archive/html/groff/2026-02/msg00025.html As noted there, it's now a documentation issue. _This_ issue is still awaiting Deri's feedback. Here's the part that jumped (from comment 15 to bug #67992). The material not prefixed with ">" is me. > Follow-up Comment #14, bug #67992 (group groff): > On Sunday, 1 February 2026 04:51:11 GMT G. Branden Robinson wrote: >> Follow-up Comment #11, bug #67992 (group groff): >> > [...] >> >> Deri, for example, is rigid in his expectations of GNU troff's >> output format ("grout", as I term it.) Where documentation doesn't >> support his rigidity, he points to the implementation as a >> specification from which no deviation should be permitted; see bug >> #63544. >> > I provided a one line perler which achieved your desire for more > readable grout (the "wish" of that bug):- > > perl -pe 's/(.)(.*)/$1\n$2/ if m/^w/; s/^(.)(\S.*)/$1 $2/mg' zfile > > I hope you are still using it. I am not. I do not see the value in filtering GNU troff's output to pre-digest it into a form gropdf requires but which no other groff output drivers do. See: https://cgit.git. ... s.sh?h=1.24.0.rc2 (Whoops--stale comment in there. I'll fix that.) > I am expecting changes to grout and groff fonts (v2) when you complete > full utf8 throughput. I don't plan "full UTF-8 throughput". I don't plan to use UTF-8 for GNU troff's internal storage of formattable character objects (rather, I plan to use `char32_t`) and moreover, even I did use UTF-8 internally, the input would still have to undergo some form of Unicode normalization; probably Normalization Form D given the program's orientation toward typesetting and support for glyph composition by overstriking. groff_char(7) has cautioned the reader to prepare for normalization of input for several years. Expecting an identity mapping between UTF-8 code points on input and the glyph encoding on output is unrealistic. > [derij@pip build (master)]$ printf ".ft JPM\nハローワールド" | groff > -Z > -k > x T ps > x res 72000 1 1 > x init > p1 > x font 41 JPM > f41 > s10000 > md > DFd > V12000 > H72000 > tハローワールド > n12000 0 Not planned. > Much nicer. And groff fonts (v2) could become:- > > ハ 1000 654 uni30CF -- 30CF > > instead of:- > > u30CF 1000 654 uni30CF -- 30CF Not planned. Both of these file formats, fortunately, admit comments, and GNU troff could emit UTF-8 in them. So I could see this instead: x T ps x res 72000 1 1 x init p 1 x font 41 JPM f 41 s 10000 m d D F d V 12000 H 72000 C u30CF # ハ h 10000 C u30ED # ロ h 10000 C u30FC # ー h 10000 C u30EF # ワ h 10000 C u30FC # ー h 10000 C u30EB # ル h 10000 C u30C8_3099 # ド (or maybe ト ゙゛, but maybe not) n 12000 0 And similarly, in a font description file... u30CF 1000 654 uni30CF -- ハ > But of course that requires both of us agreeing we are working towards > the same ends, instead of just changing grout and expecting me to > accomodate the change after the event. I've spoken elsewhere recently about how best to sequence changes. See comment #8 to bug #67939, or <https://lists.gnu ... -02/msg00000.html>. I'd expect to commit a patch (personally, most likely) to gropdf before altering GNU troff's output, adding `\s+` to regexes where necessary to achieve compatibility with the interpreter in groff's "libdriver". _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64360> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
