bugGNU roff - Bugs: bug #59932, allow characters defined with...

 
 

bug #59932: allow characters defined with .*char requests to be kerned

Submitter:  Dave <barx>
Submitted:  Sat 23 Jan 2021 04:14:08 PM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 19 Jun 2025 06:14:41 PM UTC, comment #7: 

comment #6:

>  Thanks to Dave Kemper for pointing out that user-defined characters
>  don't participate (at their boundaries) in kerning adjustments or italic
>  corrections.


I did point out the italic-correction limitation after an experiment revealed it to me.  I "pointed out" the kerning issue by quoting long-existing text in the manual (though the wording, unsurprisingly, has changed since I quoted it four years ago).  But it is good to repeat this limitation in the .char section.

Dave <barx>
Group Member
Thu 19 Jun 2025 05:26:27 PM UTC, comment #6: 


commit 6d928aad7957b7a10b289822ce445e617a978c1b
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu Jun 19 11:16:33 2025 -0500

    doc/*,man/*: Document `char` limitations.

    Thanks to Dave Kemper for pointing out that user-defined characters
    don't participate (at their boundaries) in kerning adjustments or italic
    corrections.

    Also align wording and input breaks between our Texinfo manual and
    groff_diff(7).

    See <https://savannah.gnu.org/bugs/?59932>.


G. Branden Robinson <gbranden>
Group administrator
Thu 19 Jun 2025 04:10:26 PM UTC, comment #5: 

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.)

G. Branden Robinson <gbranden>
Group administrator
Thu 19 Jun 2025 03:52:17 PM UTC, comment #4: 

At 2025-06-19T11:10:48-0400, G. Branden Robinson wrote:

> Follow-up Comment #3, bug #59932 (group groff):
>
> At 2025-06-19T03:35:03-0400, Dave wrote:
> > Follow-up Comment #2, bug #59932 (group groff):
> >
> > This is not documented, but another typographical limitation of a
> > .char definition is that it defeats even explicit requests to kern
> > with italic correction.  Observe the typeset output of:
> >
> > .nf
> > (\fIpilaf\fP)
> > (\fIpilaf\fP\/)
> > .char \[af] af
> > (\fIpil\[af]\fP\/)
>
> Slightly altering your input, we can almost as easily illustrate your
> point without requring a PDF viewer.
>
>
> $ cat ATTIC/59932-kerning.groff
> .nf
> \!# line one
> (\fIpilaf\fP)
> \!# line two
> (\fIpilaf\fP\/)
> \!# line three
> .char \[af] af
> (\fIpil\[af]\fP\/)
> $ groff -Z ATTIC/59932-kerning.groff
> x T ps
> x res 72000 1 1
> x init
> p1
> # line one
> x font 5 TR
> f5
> s10000
> md
> DFd
> V12000
> H72000
> t(
> x font 40 TI
> f40
> tpilaf
> f5
> t)
> n12000 0
> # line two
> V24000
> H72000
> t(
> f40
> tpilaf
> f5
> h1960
> t)
> n12000 0
> # line three
> V36000
> H72000
> t(
> f40
> tpilaf
> f5
> t)
> n12000 0
> x trailer
> V792000
> x stop
>
>
> The `h1960` command ("move right by 1960 basic units"), applying the
> italic correction, occurs on line two but not lines one or three.
>
> I then added `.pchar \[af]` to the end of your document, because I
> wanted to inspect the user-defined character's innards, and got the
> following marvelous surprise.
>
>
> special character "af"
>   is not translated
>   has a macro: "file name": "ATTIC\/59932-kerning.groff", "starting line
> number": 7, "length": 2, "contents": "af", "node list": troff:
> ../src/roff/troff/node.cpp:2549: void dump_node_list(node*): Assertion `n !=
> 0' failed.
> groff: error: troff: Aborted (core dumped)
>
>
> Something for me to look into, then.


One reversion of an overzealous commit of 19 May later:


special character "af"
  is not translated
  has a macro: "file name": "ATTIC\/59932-kerning.groff", "starting line number": 7, "length": 2, "contents": "af", "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


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.

G. Branden Robinson <gbranden>
Group administrator
Thu 19 Jun 2025 03:10:44 PM UTC, comment #3: 

At 2025-06-19T03:35:03-0400, Dave wrote:

> Follow-up Comment #2, bug #59932 (group groff):
>
> This is not documented, but another typographical limitation of a
> .char definition is that it defeats even explicit requests to kern
> with italic correction.  Observe the typeset output of:
>
> .nf
> (\fIpilaf\fP)
> (\fIpilaf\fP\/)
> .char \[af] af
> (\fIpil\[af]\fP\/)


Slightly altering your input, we can almost as easily illustrate your
point without requring a PDF viewer.


$ cat ATTIC/59932-kerning.groff
.nf
\!# line one
(\fIpilaf\fP)
\!# line two
(\fIpilaf\fP\/)
\!# line three
.char \[af] af
(\fIpil\[af]\fP\/)
$ groff -Z ATTIC/59932-kerning.groff
x T ps
x res 72000 1 1
x init
p1
# line one
x font 5 TR
f5
s10000
md
DFd
V12000
H72000
t(
x font 40 TI
f40
tpilaf
f5
t)
n12000 0
# line two
V24000
H72000
t(
f40
tpilaf
f5
h1960
t)
n12000 0
# line three
V36000
H72000
t(
f40
tpilaf
f5
t)
n12000 0
x trailer
V792000
x stop


The `h1960` command ("move right by 1960 basic units"), applying the
italic correction, occurs on line two but not lines one or three.

I then added `.pchar \[af]` to the end of your document, because I
wanted to inspect the user-defined character's innards, and got the
following marvelous surprise.


special character "af"
  is not translated
  has a macro: "file name": "ATTIC\/59932-kerning.groff", "starting line number": 7, "length": 2, "contents": "af", "node list": troff: ../src/roff/troff/node.cpp:2549: void dump_node_list(node*): Assertion `n != 0' failed.
groff: error: troff: Aborted (core dumped)


Something for me to look into, then.

G. Branden Robinson <gbranden>
Group administrator
Thu 19 Jun 2025 07:34:46 AM UTC, comment #2: 

This is not documented, but another typographical limitation of a .char definition is that it defeats even explicit requests to kern with italic correction.  Observe the typeset output of:

.nf
(\fIpilaf\fP)
(\fIpilaf\fP\/)
.char \[af] af
(\fIpil\[af]\fP\/)


Dave <barx>
Group Member
Wed 23 Nov 2022 10:20:37 PM UTC, comment #1: 

Updates to the "two real-world cases" in the original submission:

Dave <barx>
Group Member
Sat 23 Jan 2021 04:14:08 PM UTC, original submission:  

The Texinfo manual clearly states: "Only the current font is checked for ligatures and kerns; neither special fonts nor entities defined with the 'char' request (and its siblings) are taken into account."

This limitation seems the wrong default.  If kerning were done by default for .char-defined characters, users who want to disable kerning before or after such a character could do so with \&.  Instead, currently such kerning is inactive by default, and there is really no way to tell groff to turn it on.

Two real-world cases where this matters:

  • Bug #59839: the proffered rfc1345.tmac is a list of nearly 1700 character aliases defined with .char.  With the current restriction, no character specified with one of these aliases will be kerned.
  • Bug 58930 comment 9


On the email list, I proposed changing this behavior (http://lists.gnu.org/archive/html/groff/2021-01/msg00031.html), and while responses were extremely limited, no one opposed the idea.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.15-ef91.
    Corresponding source code