Kerning classes export problem

Primary tabs

10 posts / 0 new
Last post
Frode Bo Helland's picture
Joined: 26 Feb 2007 - 1:03pm
Kerning classes export problem
0

I'm having some trouble exporting my kern classes. They work well in Fontlab, but when I export the only letter responding is the “king” of the class. I've clicked "generate kern feature" and "compile". Does anyone know what's causing it?

Jimmy Ofisia's picture
Offline
Joined: 14 Aug 2003 - 8:39am
0

The "king" of the class? Wasn't there any error message at all?

Frode Bo Helland's picture
Joined: 26 Feb 2007 - 1:03pm
0

No error message. Here's the kern feature:

feature kern {
enum pos @_A V -50;
enum pos @_A Y -80;
enum pos @_A T -60;
enum pos @_A W -60;
enum pos @_L T -100;
enum pos @_L Y -100;
enum pos @_L V -80;
enum pos @_L W -70;
subtable;
enum pos P @_A -50;
enum pos T @_lowercasexheight -75;
enum pos T @_A -60;
enum pos V @_lowercasexheight -50;
enum pos V @_A -50;
enum pos W @_lowercasexheight -50;
enum pos W @_A -60;
enum pos Y @_lowercasexheight -50;
enum pos Y @_A -80;
subtable;
} kern;

And an example of a class:

_lowercasexheight: o' a c d e g m n p q r s t u v w x y z

The only one kerned in the exported font is o.

Ray Larabie's picture
Offline
Joined: 4 Aug 2006 - 5:54pm
0

You need at least one more OpenType feature for class based kerning to work. The kern table all on its own won't work. So, add a fractions feature, ligatures or something else. Then it should kick in.

Karsten Luecke's picture
Offline
Joined: 6 Aug 2005 - 8:41am
0

Yes. And perhaps you better avoid generating a kern table (check the export options) especially if you do not decompress kerning when you risk getting different kerning in different environments.

Frode Bo Helland's picture
Joined: 26 Feb 2007 - 1:03pm
0

Yes. And perhaps you better avoid generating a kern table (check the export options) especially if you do not decompress kerning when you risk getting different kerning in different environments.

Explain!

Karsten Luecke's picture
Offline
Joined: 6 Aug 2005 - 8:41am
0

See here. First option "Export old-style [etc]" should be deactivated. Or if you cannot resist, then at least activate the sub-option "expand class kerning while [etc]".

Frode Bo Helland's picture
Joined: 26 Feb 2007 - 1:03pm
0

Would you care to explain why? And perhaps what you mean by decompressing kerning and why that might give different kerning in different environments?

Frode Bo Helland's picture
Joined: 26 Feb 2007 - 1:03pm
0

Thanks Ray. That worked like a charm. Is this one of the legendary FL errors they never get around to fix?

Karsten Luecke's picture
Offline
Joined: 6 Aug 2005 - 8:41am
0

(What Mr Larabie alludes to is not an FLS5 bug but a bug in your version of InDesign.)

An OpenType-savvy application is expected to read kerning from the GPOS table, from one or more lookups associated with the kern feature. Defining a kern feature (which goes into the GPOS table) should do.
If you provide kerning both in the GPOS table and in a kern table, and if you do not decompress the kerning that goes into the kern table, then you have different kinds of kerning at two places in the font: full kerning in the GPOS table, keyglyph-only kerning in the kern table. And depending from which place an application takes the information, it will either get this or that kerning.

What you define in the Metrics Window is kerning for keyglyphs and perhaps exceptions. You kern only A-V but not Adieresis-V Aacute-V and expect that class definitions will care for the latter two pairs.
If you generate a kern feature and then generate an OpenType font, the GPOS table will contain full kerning as results from both your keyglyph kerning and your class definitions.
If you also generate a kern table, then FLS5 will by default only consider kerning as defined in the Metrics Window but ignore the classes. Which means that the kern table will contain kerning only for keyglyphs (and exception), kerning for A-V but not for Adieresis-V Aacute-V.*
Depending on whether an application picks the kerning from the GPOS table or from the kern table, the user will get more (GPOS) or less (kern) kerning -- and as you noticed this can be fewer kerning pairs than you want ...

* For the kern table to contain the full kerning, you need to activate the additional "decompress" option. But as said, I consider it as a bad idea to provide kerning in both the GPOS and the kern table. If an application cannot deal with OT layout tables, then the application has a problem, not the font.