[bug #58930] take baby steps toward Unicode

Follow-up Comment #7, bug #58930 (project groff): [comment #4 comment #4:] > just lamenting the total disjunctivity of the set. That two of the three, intended to serve different purposes, are disjunct seems more laudable than lamentable. But I'm not here to police your feelings. > I can't

[bug #58958] undocumented (or just broken) inability of .char to map to \:

Follow-up Comment #2, bug #58958 (project groff): [comment #1 comment #1:] > Alas, you didn't fix my typo. Copy/paste failed to fix it. I failed to notice it altogether. ___ Reply to this item at:

[bug #58930] take baby steps toward Unicode

Follow-up Comment #6, bug #58930 (project groff): [comment #5 comment #5:] > On further investigation, it appears in fact to be 0% accurate. See bug #58962. groff_char(7) is _full_ of problems with accuracy. It's on my (s)hit list. I recently fixed up the introductory material but it needs a

[bug #58930] take baby steps toward Unicode

Follow-up Comment #5, bug #58930 (project groff): [comment #2 comment #2:] > groff_char(7) (which I only now thought to check) says it > maps to \~. But that appears to be less than 100% accurate: On further investigation, it appears in fact to be 0% accurate. See bug #58962.

[bug #58962] Latin-1 NO-BREAK SPACE does not behave as documented

URL: Summary: Latin-1 NO-BREAK SPACE does not behave as documented Project: GNU troff Submitted by: barx Submitted on: Sat 15 Aug 2020 12:25:30 PM CDT Category: None

[bug #58933] [PATCH] doc/groff.texi, man/groff.7.man: clarify description of \

Follow-up Comment #3, bug #58933 (project groff): > It's Peter's term; I'm just a fanboy. I agree that "zero-width" seems redundant, but maybe he can think of something additional it communicates. It's the definition used by Ossana and Kernighan in the cstr54, not mine, though they switch it