[bug #58930] take baby steps toward Unicode

[Dave]

Follow-up Comment #15, bug #58930 (project groff):

[comment #14 comment #14:]
> I guess what we need to do here is be more clear whether
> \[u...] escape sequences are intended to represent input
> characters, or desired output glyphs.

Fair point.  I don't have an opinion either way.

But the answer has bearing on how the U+202F NARROW NO-BREAK SPACE part of the
[comment #0 original submission] should be handled.  It could be a change only
to preconv, paralleling the fix for bug #62300, making preconv convert a
U+202F on input to one of groff's thin-space escapes on output.  Or groff
itself could recognize \[u202F], which is what preconv currently outputs for
this character.

$ LC_CTYPE=en_US.utf8 printf '\u202F\n' | preconv -eutf8
.lf 1 -
\[u202F]


> _Maybe_ there's a good reason to have \^ and \| customizable
> in this way--I don't feel like I have a command of the history
> of this topic.

I don't know the history or the reasoning either, but, as you allude, there is
at least a justification for it in those two cases, where Unicode does not
specify a width.


    _______________________________________________________

Reply to this item at:

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

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