Follow-up Comment #12, bug #66675 (group groff): Hi Dave,
A couple of updates.
[comment #6 comment #6:]
> The problem is worse than originally reported as well, and has nothing to do
> with .char and its ilk.
> This also used to work as expected.
> +verbatim+
> $ echo 'Foo\[u202Z]bar' | groff -a
> <beginning of page>
> Foo<u202Z>bar
While you may be (probably are) correct that there's a problem here, 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.
Observe:
$ printf '.char \\[Unhappy] miser\\[a aa]ble\n.pchar
\\[Unhappy]\n\\[Unhappy]\n' | ./build/test-groff -a
special character "Unhappy"
is not translated
has a macro: "miser\\[a aa]ble"
special translation: 0
hyphenation code: 0
flags: 0
ASCII code: 0
asciify code: 0
is found
is transparently translatable
is not translatable as input
mode: normal
<beginning of page>
<Unhappy>
$ printf '.char \\[Unhappy] miser\\[a aa]ble\n\\[Unhappy]\n' |
./build/test-groff -Z
x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s10000
V12000
H72000
md
DFd
tmiser
C'a
h4440
tble
n12000 0
x trailer
V792000
x stop
$ printf '.char \\[Unhappy] miser\\[a aa]ble\n.pchar
\\[Unhappy]\n\\[Unhappy]\n' | ~/groff-1.23.0/bin/groff -a
troff:<standard input>:2: warning: macro 'pchar' not defined (possibly missing
space after 'pc')
<beginning of page>
<Unhappy>
$ printf '.char \\[Unhappy] miser\\[a aa]ble\n\\[Unhappy]\n' |
~/groff-1.23.0/bin/groff -Z
x T ps
x res 72000 1 1
x init
p1
x font 5 TR
f5
s10000
V12000
H72000
md
DFd
tmiser
C'a
h4440
tble
n12000 0
x trailer
V792000
x stop
> 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.)
I'm not convinced of your reasoning here, in part because (as far as I
recall), I haven't touched the code that interprets the "charset" sections of
font description files. So you can still have a special character named
"\u202Z" (in the font description file).
Instead, I think the two problems are really one. There are circumstances
where encountering an invalid Unicode special character name aren't actually
errors; they simply mean that a non-Unicode special character name is being
used. When both defining and interpolating such names, I'm rejecting them
when I should just be proceeding with what is internally a slightly different
operation. This overly aggressive rejection prevents the lookup of the
"glyph" "\u202Z" in the first place.
The other thing I want to point out is that user-defined characters' macro
contents are dumpable in my working copy. :)
Now that I've got JSON-encoding machinery in place, that was a four-line
patch.
diff --git a/ChangeLog b/ChangeLog
index da7ce7e94..697111077 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2025-03-16 G. Branden Robinson <g.branden.robin...@gmail.com>
+
+ * src/roff/troff/input.cpp (charinfo::dump): Dump user-defined
+ character definitions' macro contents. This is a JSON-encoded
+ string, but the other character properties are traditionally
+ reported.
+
2025-03-16 G. Branden Robinson <g.branden.robin...@gmail.com>
* src/roff/troff/node.cpp (suppress_node::dump_properties):
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index 71eec4fc8..6ad60425a 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -10254,8 +10254,11 @@ void charinfo::dump()
errprint(" is translated\n");
else
errprint(" is not translated\n");
- if (mac != 0 /* nullptr */)
- errprint(" has a macro\n");
+ if (mac != 0 /* nullptr */) {
+ errprint(" has a macro: ");
+ mac->json_dump();
+ errprint("\n");
+ }
else
errprint(" does not have a macro\n");
errprint(" special translation: %1\n",
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66675>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
