Too many kerning pairs

Glyphs
21

i really struggle to get under 5k pairs … so i enter »extension kerning« and a value by myself?

22

sorry to ask those dumb questions but help doesn’t offer any solution …

23

oh found it. in the font settings.

24

first test export successful. thank you, sire.

25

still struggling with the compress feature. e.g. there is a class called »i« aplied to all »i« an there are exceptions like »itilde«. when i press compress itilde exception disappears but the whole »i« class seems to have gotten the values from »itilde« and there are new pairs that didn’t exist before like @d-@i. the lock at itilde e.g. was open.

26

This is exactly what the compress feature is supposed to do – copy kerning pairs from glyphs to classes (if there is no value for the class already).

27

so should the diacritics be their own »class« each?

28

There should not be kerning to diacritics so they don’t need a class.

29

i mean itilde iacute etc

30

Usually I put them all in the i or a idieresis (all i’s with wide accents) class.

31

the point is i got it the way it is from iKern and don’t want to mess it up …

32

i just don’t get why i can’t protect my exceptions. tcaron is in the t class, scaron in the s class. there is no t-s pair, no tcaron-s, no s-tcaron. the exceptions from their groups is tcaron-scaron, both locks are open. it disappears despite open locks.

33

As explained, this is exactly what Compress Kerning does: turn exception kerning into group kerning if it did not exist before. If that is not what you want, then do not use the function, of course.

Then you need to try to reduce the amount of kerning otherwise. You can try and use my Adjust Kerning script for rounding kerning values, and then delete values below a certain threshold, e.g. 6 units.

34

Two remarks:

  1. Re: Too many kerning pairs. The number of kerning pairs that can go into GPOS is not limited.

  2. Re: Hyphens in glyphnames are forbidden with iKern. This is wrong. Hyphens are forbidden in AFDKO syntax: this because of this And since iKern’s primary output is an AFDKO syntax “kern” feature (which gets compiled fine, by the way, regardless of the number of kerning pairs), of course iKern’s output adheres to the AFDKO syntax’s rules. Otherwise, i.e. if there were hyphens in glyph names, users would get error messages when trying to compile the “kern” feature, because MakeOTF wouldn’t recognize those glyph names as glyph names.

35

[quote=“kltf, post:34, topic:2037”]

  1. Re: Too many kerning pairs. The number of kerning pairs that can go into GPOS is not limited.[/quote]

What you mean by ‘not limited’?

36

You suggested:

The suggestion to reduce the number of kerning pairs insinuates that there could be too many kerning pairs. However, for GPOS table, there is nothing like too many kerning pairs (there is, of course, but I couldn’t think of a font that would get anywhere near that). Of course you need to generate your ‘kern’ feature properly, breaking up subtables, and if necessary (most of the time it isn’t) using an extension type lookup.

37

The font is question hit the subtable barrier. All subtables are set properly (at least as good as I was able).

Extension lookups are an option but then the kerning will not work in MS Office.

So there is a limit on how many pairs you can put in a font.

38

There are size limits for tables and sub tables, and if you have a lot of group-exception pairs plus large groups, that will create a massive amount of exceptions, and then, you can get easily beyond the limits.

39

If the font hit the subtable barrier, then you did not break subtables properly. :wink: See below.

Let’s be more precise: Older versions of MS Office ignored the ‘kern’ feature if extension-type lookups were involved. Newer versions of MS Office do process extension-type lookups, starting with Word for Mac 2011. Even my contextual kerning is applied as expected, by the way.
Extension-type lookups are not the issue with the font in question, though, because:

Wrong.
First, ‘kern’ features created by iKern just work.
Second, there is no useExtension in the ‘kern’ feature created by iKern for this font in question.
Which is proof that a ‘kern’ feature can be created that a) works and b) works without useExtension.
So you’d have been more precise by saying that there is a limit to how many pairs you can put into a Glyphs font.

p.s. Rainer: Nope.