Follow-up Comment #17, bug #66675 (group groff): [comment #12 comment #12:] > the foregoing is not a valid test. > > GNU _troff_'s -a output does not resolve/interpret user-defined > characters, and that's not a new development.
True, bug #55799 has been around a while.
But one of us is misunderstanding the other. My \[u202Z] is not what I would
call a user-defined character: it's not defined by any .char (or related)
request in any roff file. I invented it by renaming an existing character in
a font description file. So while I, a user, "defined" it, from groff's point
of view it's merely a named glyph supplied by a font.
Additionally, the thing my comment #6 was pointing out _is_ a new development,
in the sense that the behavior is different between groff 1.23 and git HEAD
groff.
If any of the above contradicts your understanding of the situation, maybe we
can pinpoint where our wires are getting crossed.
> So you can still have a special character named "\u202Z" (in
> the font description file).
Well, _I_ couldn't, when I renamed the u2026 in TR to u202Z. If _you_ can, I
would love to know how you did it.
> Instead, I think the two problems are really one.
This wouldn't surprise me. I probably found two mechanisms to expose the same
bug, given that they failed with the same diagnostic. I'll know more when I
rebuild with your patch, and see how my two tests fare. I hope to tackle that
later this week.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66675>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
