strategy for kerning groups

[_ASeidel_]

Hello,<br /><br />Is there any strategy available to avoid that MakeOTF can`t access some<br />kernings?<br /><br />makeotflib [WARNING] <FONT_X> Start of new pair positioning subtable<br />; some pairs may never be accessed: [r r.alt]<br /><br />If I write the (subtable;) command I can "fix" this message but the<br />generated code is invalid.<br /><br />An other option is to split every kernig group into single kernigs, but<br />this is an enormous task and a new source of failures.<br /><br /><br /> <br />Andreas

[_Read_Roberts_]

This message shows up when MakeOTF is forced to split a lookup table in two subtables in order to separate conflicting glyph class definitions.

You may remember that in class kerning, all the left side glyphs classes that are applied in a single lookup table must be mutually exclusive; that is, a glyph may not belong to more than one left side class in a single table. Same for right side classes. When you include the same glyph in different classes on the same side in your list of kern class pairs, then MakeOTF can solve the structural limitation only by breaking the lookup table in two, such that the the conflicting classes are used in different sub-tables. However, this solves only the structural problem - you still have a functional problem. In your example, the first kern pair which uses the glyph 't' on the left side will mask any subseqent kern pair that includes the glyph "t" on the same side, as all right-side glyphs NOT paired with the glyph "t" with the first subtable will be assigned kern value of zero, and applications will never proceed to see that there are additonal kern paris with "t" on the left side. This is because for any lookup-table, all the glyphs not included in any class on the left or right side are put in an invisible class, and assigned a value of zero.

What this message should say is " you made an error in building either your left side or right side classes for use in the current lookup table- please fix the class definitions so that they are mutually exclusive."

One way to imagine all this is to imagine the class pairs as a spreadsheet of all possible class pairs. Each left side class is the title of a row, and each right side class is the title of a column. A glyph can be put in only one row title, and in only one column titile. All glyphs not named in a row title get put together in a special row title. All glyphs not named in a column title get put together in a special column title. When you specify the value of a class pair, you are specifiying the value in one cell of the spreadsheet. All cells for which no values are specified are set to 0, by default. When programs look for a kern value between "t" and something else, they look through the list of left side class definitions to find the first occurrence of 't'. By definition, the spreadsheet row for "t" defines the kern pair value of "t" with all other glyphs, and the programs does not look further. As a result, any class kern pairs with "t" on the left side in subseuqent subtables will never get seen.

Using the 'subtable' keyword fixes only the structural problem - MakeOTF can then build the feature as specified - but it is still broken from the point of view of intended function.

I am curious about the secondary problem you mention. When you use the 'subtable' keyword, in what way is the generated code invalid?

[_ASeidel_]

Dear Read,

thank you for the detailed explanation. Now I have fixed my kerning
code. - I believe it, so the kerning groups are now exclusive. But I got
this error again:

makeotflib [WARNING] < > Start of new pair positioning subtable; some
pairs may never be accessed: [r r.alt]

But the glyphs t or r r.alt are not defined or used in an other kerning
group.

Do you use a little check routine or tool to locate such trick things?
If so it would be an nice addon for the next FDK release. Sometimes I
stare at the code again and again and can`t find the bug. :-)

Andreas

[_Read_Roberts_]

There was an important typo in the last e-mail, in the sentence "All glyphs not named in a column title get put together in a spoecial row title."

The second sentence should be "All glyphs not named in a column title get put together in a special column title." The typo of interest was the incorrect use of "row" rather than the imaginative spelling of "special".

[Thomas Phinney]

I have used my God-like sysop powers to fix the typos in Read's original message.

T

[_Read_Roberts_]

I do not yet have a tool for checking exclusivity of kern classes - sounds like a good idea for the future.

I am baffled. This error should mean that you stilll have a conflict within the left or right side classes. If you can e-mail me ( directly to rroberts@adobe.com) your feature file, I will take a look at it.

[_Read_Roberts_]

I see at least one set of conflicts:
Around line 1693 in _kerning.txt is the set of statements:
pos @_kern_H r -30; #aaa
pos @_kern_M r -30; #aaa
pos @_kern_N r -30; #aaa

When MakeOTF hits line 1797:
pos t @_kern_r 20;

the use of the explicit right side class @_kern_r in line 1797 conflicts with the implicit right side class in lines 1693-1697.

If you use a class definition one one side of a kern pair, the other side gets promoted to a class as well, even if it is a class with only one glyph. The OpenType format does not allow kern pairs between a class and a single glyph. The feature file allows you to write:
pos @_kern_H r -30; #aaa
rather than the explicit:
pos @_kern_H -30; #aaa
only as a matter of convenience.

I found this by first searching for all occurrences of "t", matching case and whole words only, and then searching for all occurrences of "r", matching case and whole words only. * unsoliced ad* I use BBedit on the Mac for this kind of thiing, because of its extensive search feature and full support of regular expressions.

[_ASeidel_]

Thanks again Read,

now the code is working!



Andreas