Follow-up Comment #15, bug #67992 (group groff):
At 2026-02-01T10:48:49-0500, Deri James wrote:
> 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.savannah.gnu.org/cgit/groff.git/tree/src/devices/grotty/tests/h-option-works.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.org/archive/html/bug-groff/2026-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/?67992> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
