Include old style 'kern' tables in .ttf for applications that don't support GPOS

[taprobane99]

I use WPS Office on Linux. I notice that when I switch kerning on/off with both .otf and .ttf nothing happens to the text spacing.

However, if I open .otf verisons of source-serif fonts in FontForge and export as .ttf with "OpenType --> Old Style 'kern' " ticked, then installed the generated .ttfs, kerning works in WPS.

So can you include the old 'kern' tables (i.e long list of kern pairs) for more complete software compatibility?

I also note that LibreOffice has patchy GPOS support although I haven't tested it myself.

[frankrolf]

I understand what you are asking, but I think it might be a good question to ask “why don’t those tools support GPOS”?

The kern table was en vogue in a time when fonts had 256 glyphs at most, and a few hundred kerning pairs. At this point, Source Serif 4’s flattened kerning would be about 200K pairs – I am not even sure those would fit into a kern table. Also, I fear that adding such a table would negatively influence the file size of the font files, for minor reward.

Generally, re-compiling font binaries through a font editor is a lossy workflow. Have you verified that all kerning pairs provided via GPOS make it to the kern table in your output font? You could start with the UFO sources to get a result that’s not dependent on decompiling the OTF font binary.

Short answer: There won’t be a kern table added to Source Serif. However, you are welcome to create a fork of the project and distribute fonts with kern tables in them – but please note they can’t be called “Source” then.

Suggestion: If you have the time, please add to/file GPOS support issues against LibreOffice/WPS Office.

[taprobane99]

Linux supports, for the 'kern' format, 32 subtables with max 65k entries in each one. I verified that converting a .ttf to a .ttf with kern table does export all 200,000 entries divided into 15 subtables, the largest with 40k entries. I'm not sure of the situation on Windows or Mac.

Could you elaborate on "lossy workflow"? I am aware of the loss in converting cubic curves to quadratic curves due to fewer points per line in the later. But the conversion also works with .ttf to .ttf. So would there be any other losses there?

The thing is that WPS Office, LibreOffice, and indeed many older version of MS Office only support the older kern tables. I imagine many people may use Source Serif in word processing without being aware of this compatibility issue, and not be satisfied with the unkerned character spacing.

Would it not be possible to include a TTF_kern folder for use in desktop word processing? The file size doesn't matter for such an application.

[kenmcd]

The thing is that WPS Office, LibreOffice, and indeed many older version of MS Office only support the older kern tables.

Not true for LibreOffice. Do not know about the others.

[taprobane99]

I am running the latest release of LibreOffice (7.1.5.2) and GPOS kern doesn't work. I often find that many features LO introduces are often half-baked, or require some kind of fiddling with advanced/experimental features to activate.

huge 'kern' tables may be very inelegant for the font designer, but they work the same as GPOS for the end user, to the best of my knowledge.

[kenmcd]

Seems to be working fine for me.

Note: I have Source Serif 4 set as my default body text style so I use it daily. No issues with kerning.

[taprobane99]

@frankrolf , when I try and open a .ufo file in fontforge (for example the SmText Regular Instance), I get the following error

kerning.plist references an entity that is neither a glyph nor a group.
Could not open include file (/home/[user]/Downloads/font.ufo/../../../../../features.fea) on line 1 of /home/[user]/Downloads/font.ufo/features.fea
Unexpected token, (, on line 1 of /home/[user]/Downloads/font.ufo/features.fea