Follow-up Comment #6, bug #67817 (group groff):
[comment #3 comment #3:]
> But the character name as defined by the document is not what
> the output driver uses to produce the glyph.
Right; in fact, -a _cannot_ tell the user what the output driver would do,
because -a is not purporting to reflect the output of any particular (existing
or theoretical future) output driver, and the result of an \N lookup is not
guaranteed to be the same across drivers.
(Interestingly, Heirloom troff has no problem violating this layering:
$ LC_CTYPE=en_US.utf8 troff -a approximate.roff
Enjoy a glass of Fluermaâ„¢ tonight.
$ LC_CTYPE=C troff -a approximate.roff
Enjoy a glass of Fluerma tonight.
I'm tempted to deem this a bug--how can troff know how an unspecified
postprocessor will resolve Symbol \N'228'? But I'm less familiar with the
Heirloom architecture, and might be making it too groffy in my head.)
> another user could, with every bit as much justice, assert that
> they don't care which of several *roff input aliases were used
> to select a glyph--they want to know what ends up being
> demanded of the output device.
To accommodate this user, one would make -a output something like "<font S
entry 228>". And I'd have no objection to that: that is also far more
informative than "<--->", and won't produce a document riddled with "<--->"s
that are indistinguishable from each other.
More complex cases may have slightly less clear answers: for the definition
".char \[manyglyphs]
\N'72'\N'97'\N'105'\N'108'\N'32'\N'83'\N'97'\N'116'\N'97'\N'110'", should -a
produce the compact "<manyglyphs>", as it used to, or the galumphing "<entry
72><entry 97><entry 105><entry 108><entry 32><entry 83><entry 97><entry
116><entry 97><entry 110>"? Surely--surely!--we can agree either one of those
is more informative than "<---><---><---><---><---><---><---><---><---><--->".
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67817>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/