Follow-up Comment #5, bug #59932 (group groff): At 2025-06-19T11:52:20-0400, G. Branden Robinson wrote: > That suffices to explain the matter. The italic correction never gets > encoded into the character definition in the first place. It is > apparently silently discarded. > > Inspecting _src/roff/troff/input.h_, I observe that there is no > encoding for italic corrections of either sort. There are no > `ESCAPE_SLASH` or `ESCAPE_COMMA` symbols. > > They could be added; there appears to still be room in C1 controls for > them. But (A) I'm wondering what else we're omitting from character > definitions, and (B) why we don't warn when perform such omissions.
No, no--I'm wrong. The italic correction isn't in there in the first
place because you didn't put it there.
.char \[af] af
And an italic correction can be stuck into a character definition just
fine.
$ printf '.char \\[it] \\/\n.pchar \\[it]\n' | groff
special character "it"
is not translated
has a macro: "file name": "<standard input>", "starting line number": 1,
"length": 2, "contents": "\\\/", "node list": [ ]
special translation: 0
hyphenation code: 0
flags: 0 (none)
ASCII code: 0
asciify code: 0
is found
is transparently translatable
is not translatable as input
mode: normal
So the problem here is indeed congruent with comment #0 and comment #2.
Character definitions do not participate in kerning adjustments or
italic corrections at their boundaries.
That's worth documenting. I'll see what I can do.
Changing that/those underlying fact(s) is going to demand some design
considerations, probably best raised on the groff@ mailing list.
(I smell an analogy with an "automatic hyphenation barrier" node type
I've been contemplating, but I could be mistaken.)
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59932>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
