Follow-up Comment #56, bug #63354 (group groff): Hi Dave,
At 2025-10-15T16:21:33-0400, Dave wrote:
> Follow-up Comment #55, bug #63354 (group groff):
>
> [comment #54 comment #54:]
>> The remaining issues, as laid out in comment #0:
> ...
>> So I shall do nothing more with these issues.
>
> I stand by this regarding the cited issues, but closer inspection
> reveals a couple more minor issues lurking in this ticket's voluminous
> comments.
...for large values of "a couple", yes. :)
> * Comment #20 documents a commit that comments out the \[u200B]
> fallback, with an explanatory code comment citing the blocking bug.
> But as comment #5 explains, the bug blocks the _corrected_ fallback;
> the fallback commented out by this commit would not work under any
> circumstances.
Does that mean the comment:
.\" Mapping U+200B awaits resolution of Savannah #58958.
.\"fchar \[u200B] \h'0'\" zero-width space
...should be recast? What should it say instead?
> * Comment #39 (with support from comment #41 and comment #42) mentions
> groff ought to treat U+0082 equivalently to U+200B.
That matter should be postponed beyond the bug #40720 watershed
("Unicode [really UTF-8 input] support"), because GNU _troff_ should, in
my opinion, treat any spelling of U+0082 as equivalent to \x82 in the
input, and \x82 is forbidden and rejected in the input.
groff_char(7):
Eight‐bit encodings and Latin‐1 supplement
ISO 646 is a seven‐bit code encoding 128 code points; eight‐bit
codes are twice the size. ISO Latin‐1 (8859‐1) allocated the
additional space to what Unicode calls “C1 controls” (control
characters) and the “Latin‐1 supplement”. The C1 controls are
neither printable nor usable as GNU troff input.
U+0082 is a C1 control.
> * Comment #10 mentions that the code comment about the \[u2011]
> fallback ought to refer to bug #63360. The code comment ultimately
> added (see comment #20 again), however, says "awaits resolution of
> Savannah #63354" (the ticket you're currently reading, which is
> closed).
Here's the code in our master branch:
.\" Mapping U+2011 awaits resolution of Savannah #63354.
.\"fchar \[u2011] -\" non-breaking hyphen (won't break w/o .hcode or \:)
What should we do about it?
> * Comment #0 outlines a reason to tweak the \[u2052] fallback, and
> cites a roadblock to doing so. In comment #47 I declined to pursue
> this. However, the issue and its blocker ought to be documented in a
> code comment.
Here's the code in our master branch:
.fchar \[u2052] %\" commercial minus sign
There is no other comment.
> So a new ticket will be forthcoming after all.
Okay. I assume you mean re: U+2052. Please indicate what you think the
comment should say. :)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63354>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
