Warnings when generating OT-font ...

morten
morten Posts: 5
in Type Design Software

Hi TypeDrawers,

Unfortunately there are some kerning problems when I generate my Opentype-files ...

I have clean up my kerning-pairs etc., and when I generate a OT-file,

some pairs never occurs when I install the font and view it in for example InDesign. 

I get these ‘warnings' when I generate my OT-file – examples:


[WARNING] Pair positioning has two different values in 'kern' feature; choosing the smaller absolute value: k.sc v.sc

[WARNING] Start of new pair positioning subtable; some pairs may never be accessed:  [C Ccedilla] [G g.sc] (etc, etc ...)


When I push the buttom 'Yin&Yang' in 'Kerning Assistance', there is no errors! 

The font-file contains only 2861 pairs.


What’s going wrong? I can’t understand this.

Thanks in advance for your kind assistance!

 

Best regards from København,

Morten

Comments

  • Erwin Denissen
    Erwin Denissen Posts: 300
    Maybe you are mixing classes based with regular glyph based kerning, and they contain some overlap.

    Do send me the OTF and I'll run it through FontCreator. I'll let you know if it detects any issues.
  • Erwin Denissen
    Erwin Denissen Posts: 300
    Thank you for sending the font file. I've opened it in FontCreator, and took a quick look at the OpenType layout features. It all looks just fine.

    The kern lookup contains 63 sub tables which is a lot to go through, so it might help if you could tell us which pairs fail to work.
  • Kent Lew
    Kent Lew Posts: 937
    That Warning about the “Start of new pair positioning subtable, some pairs may never be accessed” is a classic indicator that you have overlapping kerning classes — i.e., some glyphs are members of multiple same-side kerning classes, which cause conflicting rules.

    http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html#6.b.iii

    You need to go through and clean up your kerning classes to eliminate all these conflicts before the {kern} GPOS tables can be built properly.

  • Nick Shinn
    Nick Shinn Posts: 2,207
    “only 2861…” That seems like a lot.
  • Vassil Kateliev
    Vassil Kateliev Posts: 56
    Have to agree with @Kent Lew - I have had the same problem a year ago - it is due to class overlapping - search carefully and clean up the classes!
  • Yªssin Bªggªr
    Yªssin Bªggªr Posts: 73
    I ran into something similar today. The message read "Start of new pair positioning subtable; some pairs may never be accessed" and then something about endash emdash hyphen (which are in a class) and J, Jcircumflex (also in a class).
    I checked the classes, but everything looked good.

    Finally the problem came from the fact that I created an exception (in MetricsMachine) for hyphen, [J] where hyphen is in a class with endash and emdash.
    Somehow this exception is not liked. I tried an exception for hyphen, J and Jcircumflex and this way works.

    Any ideas why? I have other glyph, class exceptions that work fine.

  • Yªssin Bªggªr
    Yªssin Bªggªr Posts: 73
    I don't know (anything about lookups).
    But why does
    enum pos Tbar [emdash endash hyphen] -40;
    work, and
    enum pos hyphen [J Jcircumflex Jcircumflex.ss01] 10;
    not?

    (Tbar is also in a class)

    This is from an exported feature file, I generate the font from Robofont without feature code for the kerning, kerning coming from the plist.


  • Ramiro Espinoza
    Ramiro Espinoza Posts: 839
    edited September 2016
    The yin-yang icon algorithm in Fontlab does not detect all kerning classes errors. Karsten's one (www.kltf.de/kltf_otproduction.htm) is much better.
  • Kent Lew
    Kent Lew Posts: 937
    The issue is related to where the compiler needed to put a subtable. That subtable break was going to end up splitting the enumerated pairs into different subtables. But since the same target (hyphen, in this case) would be in both subtables, only those pairs in the first subtable would be found and the others would be ignored.

    By creating explicit exception pairs with only some of the second members, it seems you were able to get them to all fit in the same subtable.

    This issue is not really a kerning class error, per se, in terms of the source data (so the yin-yang shouldn’t be expected to find it). It is a result of compiled format limitations. Your data is pushing up against table size limits.

    The problem is not with the “enum pos hyphen @J_class" rule itself. It just happens to affect that particular data coincidentally.

    It’s conceivable that if you edit your kerning data and add more exceptions, the issue will reappear regarding a different set of exceptions that currently compiles fine, wherever the subtable split now happens to occur.

    Subtabling is an arcane thing and challenging to anticipate and manage.

  • Yªssin Bªggªr
    Yªssin Bªggªr Posts: 73
    Thanks for the explanation Kent!

    In some way that is a good news, it's an invitation to not go too crazy and do a bit less kerning :smile:

    (not working in FL anymore so the ying-yang is not an option anyway, but I was relatively sure it wasn't a class thing).

Categories