bugGNU roff - Bugs: bug #64519, font description file should allow...

 
 

bug #64519: font description file should allow kern pairs with arbitrary printable glyphs as first element

Submitter:  Dave <barx>
Submitted:  Mon 07 Aug 2023 03:19:11 AM UTC
   
 
Category:  Font - others/general 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
   

Wed 09 Aug 2023 08:47:21 AM UTC, comment #1: 

How about dashes?

Let's add excessive kerning between a dash and some other character to easily see whether it's being honored.

First, satisfy yourself that there are no dashes already specified in the kernpairs section.

$ sed -n '/^kernpairs/,/^$/p' /usr/share/groff/current/font/devps/TR | grep 'e[mn]'

Now let's define one for the en dash.  The commands below require a sed that puts newlines in the output when a \n appears in the replacement pattern.  Adventures in bug #64061 tell us this is many but not all seds.

$ mkdir -p /tmp/groff/devps
$ export GROFF_FONT_PATH=/tmp/groff
$ cp /usr/share/groff/current/font/devps/TR /tmp/groff/devps
$ sed -i '/^kernpairs$/aT en -500\nen T -500' /tmp/groff/devps/TR
$ printf '.nf\nT\(enU\nU\(enT\n' | groff > output_file.ps

Looking at output_file.ps reveals that, as hoped, these new kernpairs "kern" the en dash and the T by substantially backing them over each other, so the effect is easy to see.

What about doing the same thing with the em dash?

$ sed -i '/^kernpairs$/aT em -500\nem T -500' /tmp/groff/devps/TR
$ printf '.nf\nT\(emU\nU\(emT\n' | groff > output_file.2.ps

Frustratingly, the kern pair starting with the em dash fails, just as the hyphen did and the en dash didn't.

So at the moment it appears hit or miss whether a given nonalphabetic glyph can be the left one of a kernpair.  I'm sure there's a systematic way to test all the glyphs in the font, but I hope that root-cause-analyzing the hyphen and em dash failures will reveal any other affected glyphs.

(Remember to tidy up after yourself.

$ rm -rf output_file.ps output_file.2.ps /tmp/groff
$ unset GROFF_FONT_PATH

If you leave the /tmp directory in place and GROFF_FONT_PATH in your environment, you'll get some rather ugly typography later when you don't intend it!)

Dave <barx>
Group Member
Mon 07 Aug 2023 03:19:11 AM UTC, original submission:  

Today we examine a three-pronged problem.

I. font description file


Any pair of glyphs in the "kernpairs" section of the font description file where the first glyph is a hyphen is ignored.

This is not immediately obvious, because none of the font description files groff ships for the ps or pdf devices has such a kernpair:

$ egrep '^(-|hy) ' font/devp*/* | wc -l
0

However, my system has a font family that contains such pairs: Linux Libertine, whose roman font I've locally named LR:

$ egrep '^(-|hy) ' /usr/share/groff/site-font/devps/LR | wc -l
80

So let's look at one such kernpair:

$ egrep '^(-|hy) W ' /usr/share/groff/site-font/devps/LR
- W -48
hy W -48

I chose this one because it has one of the larger adjustments of any of the 40 kernpairs beginning with a hyphen, so any change ought to be visible to the naked eye, especially at a large enough type size.

So let's craft an example with a large type size and see what we see.

$ cat kern-test
.fam L
.nf
.ps 60
.vs 80
.sp
MAKE-WORK
MAKE-\&WORK

The "- W" (or "hy W") kernpair in the LR font description file ought to visibly reduce the space between the hyphen and the W on the first line of the PostScript output.  This should be visible by contrast with the next line, where the dummy escape prevents kerning in that spot.

But in the generated output, the two lines look distressingly identical.

Just to verify to ourselves that our naked eye is not failing us, we can generate each line separately and algorithmically compare the results:

$ diff <(fgrep -v E-W kern-test | groff) <(fgrep -v \& kern-test | groff) | wc -l
0

The hyphen-W kernpair has no effect.

This does help explain the side note in comment 3 of bug #57448.

Groff's own TR font description file contains the opposite kernpair, a W-hyphen one, and it's trivial to demonstrate via similar means that this does have a visible effect.  As with all lecturers who hand-wave away "trivial" demonstrations, I leave this one as an exercise to the reader.

II. documentation


This lack of efficacy, like the similar one with a space as the first element of a kernpair (bug #58718), is undocumented in the info manual's three sentences that explain how items in the "kernpairs" section work.

But one might harbor suspicions that there would be some difficulty defining a space as the first element of a kernpair, because the "kernpairs" section uses spaces to delimit the elements.  The hyphen, represented as either "-" or "hy", should present no such difficulty, so this behavior really defies expectations.

III. afmtodit


It further turns out these nonfunctional hyphen-leading kernpair lines were placed there by groff's own afmtodit:

$ head -1 /usr/share/groff/site-font/devps/LR
# This file has been generated with GNU afmtodit (groff) version 1.22.2

One piece of groff software should not generate lines that are ignored by another piece.

The fix


But I believe these kernpairs should work, and I've filed this bug accordingly.  That is, rather than documenting the limitation and fixing afmtodit to honor it, I think groff should use such kernpairs.

Aesthetic value is subjective, but I suspect most people with a typographical eye would agree that the PostScript output is more pleasing with the adjustment that the font description file requests.  You can compare the lines with and without the adjustment by faking the kerning in our trusty "kern-test" file from above:

$ sed 's/&/h"-0.048m"/' kern-test | groff > kern-test.ps

In this case the difference is visible to the naked eye--at least, to eyes as discerning as yours.  The hoi polloi may not see any difference, but you and I know good typesetting when we see it!  *conspiratorial wink*

This example uses font LR, but if you don't have that, you can demonstrates the principle just as well using groff's own TR.  In this instance we'll use a slightly larger adjustment, reflecting the TR font's adjustment in the W-hyphen case.

$ fgrep 'W - ' /usr/share/groff/current/font/devps/TR
W - -65
$ fgrep -v .fam kern-test | sed 's/&/h"-0.065m"/' | groff > kern-test.ps


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

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-08-09 barx Summaryfont description file should allow kern pairs with hyphen as first element font description file should allow kern pairs with arbitrary printable glyphs as first element

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code