Follow-up Comment #13, bug #40720 (group groff): At 2025-12-01T23:19:45-0500, Dave wrote: > Follow-up Comment #12, bug #40720 (group groff): > > Fun fact: when > [http://git.savannah.gnu.org/cgit/groff.git/commit/?id=e7c9dbd20 > commit e7c9dbd20] introduced preconv, the log message included the > sentence "Not yet integrated within groff," implying that preconv was > intended to be integrated at some point.
On the one hand, "groff" != (GNU) "troff" when we're talking about specific executable programs. On the other, maybe integration with the _groff_(1) front end is what was contemplated. I'll chop off a third hand by observing that integration into _groff_, the _project_, was achieved by the selfsame act of committing. Smuggling a fourth hand from an unmentionable place, I'll say that I see little reason to "integrate" _preconv_ any more tightly than it already is. It's an even more UTF-8 world now that it was when _preconv_ was born, and since GNU _troff_ will almost certainly throw diagnostic messages if given invalid UTF-8 sequences on input, it shouldn't be hard to for the user to deduce when preprocessing with it is required (and the wording of our diagnostic messages can help with this), but absent. Contrast the mojibake one gets today because there's no such thing as an invalid Latin-1 sequence. https://old.reddit.com/r/groff/comments/1pajc59/how_to_fix_that/ _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?40720> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
