Follow-up Comment #6, bug #66675 (group groff): The problem is worse than originally reported as well, and has nothing to do with .char and its ilk.
$ echo 'Foo\[u202Z]bar' | groff -a
<beginning of page>
troff: <standard input>:1: warning: can't find special character 'u202Z'
Foobar
That's expected. However, you can edit your font file (in this case the
default one, devps/TR) to include a character named u202Z. (For simplicity,
rename the existing u2026 to this.) U+202Z is not a valid _Unicode_
identifier, but u202Z is a perfectly fine groff character name: as you point
out in comment #3, groff character names can start with a "u" without being
Unicode characters.
This also used to work as expected.
$ echo 'Foo\[u202Z]bar' | groff -a
<beginning of page>
Foo<u202Z>bar
You can also generate PostScript output and verify that your new character is
there. If you took my advice and renamed u2026, you'll see an ellipsis
between the "Foo" and the "bar".
But this no longer works in the latest groff.
$ echo 'Foo\[u202Z]bar' | groff-latest -a
<beginning of page>
troff:<standard input>:1: error: special character 'u202Z' is invalid: Unicode
special character sequence has non-hexadecimal digit 'Z'
Foobar
This is the output from a current groff build even _with_ devps/TR modified to
include a character named u202Z. Thus the latest groff prevents access to
this character in the font file.
And this has nothing to do with .char definitions. So it sounds like the mode
in which groff reads the first argument of one of these requests is a red
herring. (It sounded like that to me anyway, since you imply that the first
argument being read in interpretation mode is an age-old practice, whereas
this failure is new. But I wanted to confirm.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66675>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
