Collapsing class kerning more precisely

[Ray Larabie]

I have FLS set to automatically collapse the class kerning table to 2048 kerns. I can choose a codepage, fine but how can I get more control over what kerns get higher priority? In some of my fonts, kerns in the A-Z, a-z, commas and quotes are being cut off while base quotes, ellipsis, emdashes and accented letters get collapased kerns. I'd like to be able to specify the bare minimum, top priority kerns that need to be collapsed before lower priority kerns. This is especially a problem with web embedding because browsers don't support class kerning.

What's the best way to accomplish this? Should I create a custom encoding table containing my high priority kerns, collapsing those, then collapse another table with lower priority kerns? Can I rearrange an existing encoding table to put higher priority kerns closer to the top?

The way I've been doing it: I make a copy of the font and remove all low priority glyphs. I collapse kerning, save metrics, import the collapsed kerning back into the main font, then collapse kerning to fill up the 2048.

[Luc[as]]

Hi Ray,

I'd say you want to filter, not collapse your kerning. The word collapse sounds like transfering flat kerning into classes with the "compact" button. When a card house collapses, you don't lose cards. This is not my native language, is my understanding correct?

I collected and analyzed languages for over a decade, and have a filter programmed where you can set priority for one or more languages (or prioritize by amount of speakers), you can slide priority between real life occurrence and kern amount, you can select quote styles to keep or delete, and of course the maximum amount of pairs to keep in the font. So that only the most important pairs (for your settings) remain.
The filter runs on one of my PCs, but unfortunately is not an installable product (yet). A bug to fix, things to add. Newspapers often have low kern amount limits. Less kerns is shorter production time.
If I only knew how to kick my programmer into picking up this project again... How much demand would there be?

[Ray Larabie]

I'm sorry, expand is the term used n Fontlab, not collapse.

That sounds interesting: a smarter way of expanding class kerning. I think there may be some demand now but when all web browsers eventually support class based kerning it will be less irrelevant. Judging by the amount of response to my question, I think demand might be low but at least you'll have one customer.

Fontlab coders: if you were trying to expand kerning but simply restricted it to specific glyphs, what would be the best way to do it?

[Ray Larabie]

Perhaps I can phrase the question another way: what can I do to affect the priority of Fontlab's kerning expansion? I know how to limit it but how do I affect the priority? Does to order of classes have any effect? When I expand kerning and limit the number of pairs, FontLab has to make a decision as to which pairs will be omitted. How is this decided? I know you guys are busy with new versions of FontLab but and little insight on how I can control kerning expansion will really help me support apps which don't support kerning classes.

[Dezcom]

Does the browser get in the act or is this something only the font controls?

[Ray Larabie]

Expanding kerning can be used to automatically add kerning pairs. Those pairs are redundant for apps which support OpenType kerning classes.

When you expand kerning classes, applications which don't support OpenType kerning classes can still display the expanded kerning. It's not as good as class kerning as the number of pairs is limited, but it's better than nothing.

Example: All my fonts allow Cufon embedding. Cufon embedding doesn't support kerning classes. If I didn't expand the kerning classes, only the class parents would be kerned. In my case, that would mean no kerning for commas, smart quotes, double straight quotes, base quotes. In some cases, no kerning for Q and V. In an all caps font, the "lowercase" glyphs would have no kerning at all. So some kerning expansion is always necessary when generating OpenType fonts . . . . unless you don't care how your fonts look in apps which don't support OpenType classes. Of course, I could manually copy the kerning to important glyphs but that's not going to happen.

I limit the number of kerns I expanded to 2048. I've found that expanding too many pairs can cause all OpenType features to break in some apps. Let's say I have an all caps font with a few hundred accented glyphs. I have a font called Meloriac which is an all caps geometric. The O is a parent to a lot of other circular glyphs. There's very little kerning for the class parents. If I didn't set a limit for the number of pairs that wpould be expanded, the kerning would expand to over 36000 pairs. I'd hate to expand to 2048 kerns and find that Vietnamese accents took higher priority than the comma, quotes or the "lowercase" set.

33952 pairs will be omitted when I expand. How does the expand kerning code decide which glyphs get kerned first? Does the order of classes have any effect of the priority or expansion? What about the order of child glyphs within each class? The reason I am asking is because out of habit, I create classes for period, quotes and hyphens last. Since they should be high priority glyphs, should I putting those classes at the beginning? Does the index, name table or unicode order have an effect on kerning expansion priority?

I'm away that I can limit expansion to a certain codepage, but how is priority decided within that codepage?

Perhaps the only person who can answer this is the person who wrote the code for expanding kerning. I'm hoping one of the FL coders will take notice of this thread.

[Arno Enslin]

@ Ray

You could make a test for finding out, which pairs have priority. You can limit the maximum number of pairs to less than 2048, 100 pairs for example. Then you build class kerning, that results in 110 expanded kerning pairs. 100 of them are combinations of letters. And ten are combinations of letters and point, comma et cetera.

Additionally you could create your own codepage, which you select in the font window and in the drop down menu "generate only pairs with glyphs in following codepage".

Edited:

I assume, that those pairs with the most extreme values have priority; this would make sense.

Edited 2:

I did not check, if it works, but in this way you could create your own codepage:

1. Remove all characters from your font, that shall not be in your codepage. Every character should have an Unicode value, even if it is a value that belongs to the private use area.

2. Generate the font.

3. Decompile the cmap-table with TTX.

4. Open the decompiled cmap-table in a powerfull text editor like UltraEdit. (A file with character names and Unicode values.)

5. Search and replace with regular expressions and create a syntax like this one:

Code: [Select]

%%FONTLAB CODEPAGE: 0xFFFF; Ray
0x41 0x0041 % LATIN CAPITAL LETTER A
0x42 0x0042 % LATIN CAPITAL LETTER B
0x43 0x0043 % LATIN CAPITAL LETTER C
0x2D 0x002D %HYPHEN-MINUS
0x2E 0x002E %FULL STOP
0x2F 0x002F %SOLIDUS
0x30 0x0030 %DIGIT ZERO
0x31 0x0031 %DIGIT ONE
0x32 0x0032 %DIGIT TWO
0x33 0x0033 %DIGIT THREE
6. Save the file with the extension ".cpg" in the FontLab folder, in which the codepages are stored. On Windows this is "FontLab-installation-folder\codepage".

7. (End and) restart FontLab.

Addition:

If you want to change the unicode later, that should not be a problem. TTX also can decompile the kern-table. And the kern-table can merged into a font with different unicode values. You must not change the character names only.

I strongly recommend TTX. With the help of batch files it is very easy to use. Alternatively you may give OTMaster a try, but I think, that the prices of DTL products are elitary and I like free open source products, projects, which everyone is allowed to improve. I am for my part very contented with TTX.