[bug #58930] take baby steps toward Unicode

[Dave]

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 think of a more appropriate mapping for it.

Well, if there were a more appropriate mapping for \[u00A0], that mapping
should also apply to the Latin-1 A0.  They're the same character, just with
different input representations.

Speaking more generally, for a Latin-1 input file, "groff latin1.txt" and
"groff -Klatin1 latin1.txt" should produce identical output.  Presently, for
this character they do not.

> Might as well sweep that one into this report, then.

As long as it doesn't change the billing, I won't complain about you doing
more work than I asked for.

> tmac/pdf.tmac sources tmac/ps.tmac so the fix only has to be made in one
place.

I should have said "notably but not limited to -Tps and -Tpdf."  Fixing this
in the device-specific tmac file then requires duplicating that fix for at
least -Tascii, -Tlatin1, and the various -TX* devices, and I couldn't even
begin to guess about the more obscure legacy devices.

On the one hand, I get that \[u2011] is a character, and characters are mapped
to glyphs, and glyphs reside in fonts, and fonts are device-specific, so some
device-specific code seems a reasonable place to handle it.

But zooming out, the semantics of U+2011 NON-BREAKING HYPHEN are not
device-specific; as an output glyph, it is always identical (as you note) to
\[hy], or \[u2010].  What separates them is its behavior--and this should be
the same across all devices, suggesting it should be handled in a
device-independent section of the code.

I mean, I don't want to back-seat drive, and tell you your very simple
solution, which covers most output formats most people care about, isn't good
enough--except I guess I do, because that's kind of what I'm doing.

    _______________________________________________________

Reply to this item at:

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

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