[bug #57618] man/groff_char.7.man: page needs an overhaul

[Dave]

Follow-up Comment #11, bug #57618 (project groff):

[comment #8 comment #8:]
> This sounds like a bug in (1) preconv for not emitting
> composite Unicode glyph escapes and (2) troff for failing to
> accept them--but that would require more state tracking.  Maybe
> we could add a heuristic into troff with a hard-coded table of
> combining characters so we can tell the user to put the input
> \[uXXXX_YYYY] form.  There's already a big table for detecting
> invalid UTF-8 sequences, so it could probably fit in there.
> I'll see what I think after actually looking again at the code.
> 
> I note regarding point (1) that if we implement my proposal in
> bug#58796, the frequency with which such things will have to be
> emitted will drop off precipitously.
> 
> And (3) I reckon we need to clarify what we mean by "NFD".
> We mean "decomposed and expressed as composite Unicode special
> character escapes" (whew!).
> 
> Could I trouble you to file these?

You know me, any excuse to file new bug reports.

But if (2) is a legitimate bug, I'm not sure (1) is: if troff accepts whatever
form is thrown at it, it shouldn't matter which form preconv emits.  (Vice
versa is less true, since users can always directly embed \[uNNNN] escapes
directly in their source, meaning troff should be equally conversant with
"\[u006F_0308]" and "o\[u0308]", unless we specifically document that the
latter is disallowed.)

And (3) seems dependent on where the discussion of comment #10 goes.

So I reckon for now I'll deny myself the satisfaction of opening new bug
reports till I get a better handle on what they should be reporting.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57618>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/