Support for Open Font Format kerning tables

[reffort]

One of the things I was working on, way back when, was adding support for Open Font Format kerning. This is a form of kern table that is used by nearly all commercial fonts, but few free fonts. Heirloom and n-t-roff do not know about this table, which results in the kerning values being read incorrectly from the font file. (The OFF spec was released around the time Gunnar was winding down with Heirloom, so it is not at all surprising that there is no support for this table.) The modifications were essentially complete back in 2018--the only things needed were to remove the debugging and trace messages--but that was in the same time frame I was running away from Github as fast as I could, and I abandoned it. I ran across the files this past weekend while going through an old unused drive, and decided that they weren't doing anybody any good just setting there.

1-otftest-before.pdf

2-otftest-after.pdf

testfiles.zip

The two PDFs are "before" and "after" text samples showing the effect that using the OFF-style kern table can have. The effect is generally subtle (the text looks less jittery) and varies from font to font. The difference is obvious in print, although I think the improved character spacing can be seen even on a screen. The demo shows three fonts: Cochineal, an OTF free font; Kings Caslon, a TTF commercial font; and Warnock Pro, an OTF commercial font. The difference is most apparent on the Kings Caslon sample. Warnock is much less affected, but it takes on an almost buttery smooth color with the correct kerning. Fonts that do not use OFF-style kerning are not affected--the kerning is already correct for them. To run the test files, they will need to be modified to reflect each installation and to use the desired fonts.

The code changes are minor, just a matter of reading the table from the font file and hooking up the wires. This zip file contains the full (modified) otf.c file and a git diff vs. the previous version (from 2015), showing the changed lines. The current otf.c on Github is newer and has been updated to appease Clang, so applying the diff file to the current otf.c without human interpretation will undo those changes.

Source.zip

I've been unable to get the n-t-roff project to build successfully on my current machine. The compiler exits with several linker errors of the form /usr/bin/ld: eqnbox.c:(.text+0xe8): undefined reference to 'yyval'. If this is (still) the old Bison-related issue, it might be worth while to change the build process so that it uses only known-good files, and the yacc/lex/sed-related parts are not invoked--they would be relegated for use only in a development context.

[aksr]

@reffort: Why did you close this?

[n-t-roff]

YACC and LEX are not a problem, but the source code of the lex file needs to be changed to not use internal variables. Then the (not working) sed call is not needed anymore. I do not have the time to do any software development anymore but it would be good if someone fixes these lex files. I had done this for DWB in the past which worked well.

[reffort]

I closed it because I just wanted the files to reside somewhere other than on my old, unused local drive. The code worked in the older version of n-t-roff, but I didn't have any luck getting the current version to compile on my machine so I could run tests (the corresponding n-t-roff file has changed since then). It would take soneone's time to do that, and this is not any kind of priority item.

Sent with Proton Mail secure email.

On Friday, March 22nd, 2024 at 1:15 AM, aksr @.***> wrote:

@.***(https://github.com/reffort): Why did you close this?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[n-t-roff]

@reffort thank you for sharing the files. I reopened it in case somebody else will have the time to integrate these valuable features.

[phonologus]

I've hand-grafted @reffort 's diffs into the current otf.c. Compiled and built successfully (macOS 14.2). @reffort 's test with Cochineal (I don't have licenses for the other two) seems to work, and produces identical (to my eye) output, most obviously very tight kerning between A and V.

Here's the diff file against the current otf.c (apologies for the .txt extension, but Github doesn't support .diff...):

otf.diff.txt

[n-t-roff]

Thank you very much for working on this. Is it possible for you to create a pull-request for this patch?

@reffort I would appreciate if you could have a look at this patch. Thank you very much in advance