Home› Type Design Software
Options

Warnings when generating OT-font ...

mortenmorten 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

  • Options
    Erwin DenissenErwin Denissen Posts: 291
    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.
  • Options
    Erwin DenissenErwin Denissen Posts: 291
    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.
  • Options
    Kent LewKent Lew Posts: 905
    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.

  • Options
    Nick ShinnNick Shinn Posts: 2,146
    “only 2861…” That seems like a lot.
  • Options
    Vassil KatelievVassil 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!
  • Options
    Yªssin BªggªrYª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.

  • Options
    Yªssin BªggªrYª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.


  • Options
    Ramiro EspinozaRamiro 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.
  • Options
    Kent LewKent Lew Posts: 905
    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.

  • Options
    Yªssin BªggªrYª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).

Sign In or Register to comment.