Is it possible to add languages AFTER I already kerned a font? I have a customer who needs Greek and Cyrillic added to an existing font and a lot of the glyphs are similar to Latin. Just don’t want to kern the lot again…
That’s pretty common. Kerning Greek and Cyrillic can be a little tricky though; taking Cyrillic for example, you may want to put common letters in the same kerning groups (e.g. A and A-cy in the same group), which is how I kern by the way. The question arises before you ship; do you want to separate kerning groups into scripts and allow no script mixing? Or do you want to generate the font anyway?
- The former approach (split groups) was recommended by Adobe’s Frank Grießhammer in one of his conference talks some years ago. His point was that the layout engine flattens kerning into a table at runtime and creates a whole bunch of useless pairs (Lat-Cyr), thus eating up memory. I have a Glyphs script that splits the groups.
- The latter approach likely requires ‘Use Extension Kerning’ custom parameter, but that’s it. It may be more memory-intensive, but may not matter much nowadays. It was recommended by Adobe’s Ken Lunde (now Apple).
There seems to have been a disagreement even within Adobe, so I don’t know which to recommend. I usually take the latter route though.
4 Likes
@Tosche - You always have amazing answers, thanks!
I know that adding non Latin glyphs in Latin kerning groups results in useless pairs, but it does make life a bit easier.
Some time ago, I posted a thread about Vietnamese: I had made a font, kerned it and then decided to add Vietnamese. I added those glyphs to the kerning groups and then discovered that the Vietnamese glyphs did not follow the rest. I think you told me that I should have added Vietnamese BEFORE kerning… as in, the font had kerning and did not accept new glyphs being added…
You can find the thread here.
To clarify what I meant, the kerning process itself is simple and the same; add Greek and Cyrillic glyphs to the existing Latin pairs as much as possible, make new ones as necessary, and kern. The difference between the split or merged approaches come just before the export, and are both a few clicks away.
(I forgot to mention that the group splitting is an irreversible operation; when I take the split route, I usually run the script, export, then close the file without saving.)
For my fonts I usually keep the multi script classes. I did run some tests and the file size was worse with split classes. Other fonts might produce different results but I think it will not be much worse.
Is there an easy way to check and compare the memory load?
What do you mean by memory load? In the app that is using the font? That really doesn’t matter. It was maybe relevant 20 years ago.
What is relevant is the size of the GPOS table/lookups. Reducing the size might reduce the need to use extension lookups.
As Frank explained (much closer than 20 years ago), the layout engine flattens the kern feature and makes a lookup table in the memory. Mixing scripts results in much larger table than necessary. And Ken Lunde said it didn’t matter, and so do you, but I have never measured which is true.
I don’t think a table like this is in any way a performance concern, nowadays. It might be if you run the font on a micro-controller or something constrained like this.
Sorry for opening an old topic but I’m making myself a sample list for kerning and wanted to know if there has been any consensus in the meantime as to whether it’s worth splitting kerning into scripts or if it’s just an unnecessary process and script mixing between Latin, Cyrillic, Greek doesn’t bother anyone . Just to be sure.
I’d also be very interested in hearing a confirmation of the best practise (of today) regarding this subject.
Is it best to keep kerning of different scripts together (sharing kerning groups) or should the kerning of each script be split?
I usually keep the kerning/groups together. Much easier to work with. And didn’t have problems with it.
Check. Thanks Georg!
I also use common kerning groups between scripts that have many common forms, such as Latin, Greek, Cyrillic.
And here is a comment about script-dependent kerning, from John Hudson on TypeDrawers:
I create separate kerning lookups for each script, and a shared lookup for numerals-to-numerals. At least, that is how I handled it in the Brill types.
Some more recent projects use a unified source, in which all the kerning gets rolled into a single set of lookup subtables. I don’t like it, because it is inefficient at the text processing stage, but it is more convenient at the font tool stage.