Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues in getKerningPairsFromOTF.py #2

Open
behdad opened this issue Apr 20, 2017 · 2 comments
Open

Issues in getKerningPairsFromOTF.py #2

behdad opened this issue Apr 20, 2017 · 2 comments

Comments

@behdad
Copy link

behdad commented Apr 20, 2017

cc @justvanrossum

I read the code and noticed a few issues. Most of them don't affect well-constructed font, but one issue I think is rather serious. Though I have not debugged code to confirm. Hre it goes:

In the following code:

    lg = myLeftClass()
    lg.class1Record = class1Record
    leftClasses.setdefault(class1Record, lg).glyphs.append(leftGlyph)
    self.allLeftClasses.setdefault("class_%s_%s" % (loop, lg.class1Record), lg.glyphs)

(same is repeated for right glyph as well)

The problem is, in my understanding, that if class1Record was already in leftClasses, then leftClasses.setdefault(class1Record, lg) returns the existing leftClasses.setdefault[class1Record], which is different from lg. Then leftGlyph is corrected appended to .glyphs of that object. However, the next line, uses lg.glyphs, which is not outdated! To correct, you should also update lg:

    lg = myLeftClass()
    lg.class1Record = class1Record
    lg = leftClasses.setdefault(class1Record, lg)
    lg.glyphs.append(leftGlyph)
    self.allLeftClasses.setdefault("class_%s_%s" % (loop, lg.class1Record), lg.glyphs)

I don't know; if my assessment is correct, then this should be broken for every font. But apparently that's not the case. I haven't debugged it.

Issues that only show up in badly-constructed fonts:

  1. The code reads glyph- and class-based subtables separately. This is a problem if a class-based subtable processes a left-glyph that also shows up in a glyph-based subtable that comes later.

  2. If two subtables of the same kind both cover the same glyph pair, the first one should win, but the way the code is written, the last one wins. That's easy to fix, just reverse the subtable order at the end of getPairPos().

  3. In getClassPairs(), the code iterates over all glyphs defined in ClassDef1. However, if there's a glyph in ClassDef1 that is NOT in Coverage, that glyph should not be processed. So, better to intersect the classes with coverage first. This function from varLib might come handy (copy it; I'll move it somewhere proper later):

https://github.com/fonttools/fonttools/blob/86549315fdab659cfc536d0af7f2d2a56da176d5/Lib/fontTools/varLib/merger.py#L295

Now I noticed that I should intersect classes with allGlyphs in that function as well.

@frankrolf
Copy link
Member

Thanks @behdad! I will have a look.

@behdad
Copy link
Author

behdad commented Apr 27, 2017

Fixed _ClassDef_invert(): fonttools/fonttools#939

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants