UNSOLVED Metrics Machine freezing on Groups update



  • I am working on updating / building groups in Metrics Machine, and I have hit the same blocker 3 times so far today. I’m wondering if anyone may have any suggestions on how I might avoid it in the future, and I partly hope it might be something that could be further improved in future versions of MM.

    The Problem

    I have added more glyphs to a font (Name Sans Text Bold, WIP), and I am now updating groups to account for this.
    Unfortunately, when I go to “Apply” those updates, I get a progress bar, “Searching for conflicts...” and it unfortunately hangs on this.

    ![0_1594681319183_e5b1707d-74f2-41f4-bbfd-a9e07edbd144-image.png](Uploading 100%)

    The Output Window includes the following:

    Traceback (most recent call last):
      File "/Applications/RoboFont.app/Contents/Resources/lib/python3.7/vanilla/vanillaBase.py", line 503, in action_
        self.callback(sender)
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/interface/groupEditSheet.py", line 188, in applyCallback
        needResolution = groups.metricsMachine.applyGroups()
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/objects/mmGroups.py", line 1509, in applyGroups
        pairs, haveConflict = self._searchForConflict(superPairData, superPair, finalValue)
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/objects/mmGroups.py", line 1633, in _searchForConflict
        haveConflict = self._tryToCompressPair(superPairData, superPair)
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/objects/mmGroups.py", line 1708, in _tryToCompressPair
        left = self[superSide1]
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/objects/mmGroups.py", line 71, in __getitem__
        return self.super()[groupName]
    KeyError: 'public.kern1.x'
    Traceback (most recent call last):
      File "lib/doodleDelegate.pyc", line 96, in sendEvent_
      File "/Applications/RoboFont.app/Contents/Resources/lib/python3.7/vanilla/vanillaBase.py", line 503, in action_
        self.callback(sender)
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/interface/groupEditSheet.py", line 188, in applyCallback
        needResolution = groups.metricsMachine.applyGroups()
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/objects/mmGroups.py", line 1509, in applyGroups
        pairs, haveConflict = self._searchForConflict(superPairData, superPair, finalValue)
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/objects/mmGroups.py", line 1633, in _searchForConflict
        haveConflict = self._tryToCompressPair(superPairData, superPair)
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/objects/mmGroups.py", line 1708, in _tryToCompressPair
        left = self[superSide1]
      File "/Users/stephennixon/Library/Application Support/RoboFont/plugins/MetricsMachine.roboFontExt/lib/mm4/objects/mmGroups.py", line 71, in __getitem__
        return self.super()[groupName]
    KeyError: 'public.kern1.x'
    

    Previous times, I have had KeyError: 'public.kern2.quote' and KeyError: 'public.kern1.quote'.

    Sure enough, I did have those groups referenced in my kerning.plist, but not in the groups.plist. Admittedly, this is due to some scripting done outside of MM, so this may be where Tal’s hands are clean of the issue.

    For example, the first errors were from an earlier generic quote group that was later split into quoteleft, quoteright, and quotesingle, but as it turns out, even though the groups were updated, the old kerning data hung around to bite me now.

    Similarly, I had changed kerning from a k group to an x group, but then copied things around between UFOs.

    I am actually unsure of how MM might help solve this kind of issue, as it comes from factors outside of MM’s control. But, I suppose, I would much rather MM ran checks before I edited groups, rather than after? It is definitely a bit difficult to spend time editing groups, only to have the app freeze and require a force quit.

    Thanks for any potential suggestions if you might know of a good way to efficiently avoid future such clashes (or detect them before editing groups)! At the very least, by posting this, I will hopefully help others avoid or debug the issue for themselves.


  • admin

    ehum, if the data is incorrect its hard to find a solution for this issue.

    MM is build as such this doesn't happen :)

    I dont know what should happen in this case:

    • MM should not create empty kern groups
    • MM should not return empty list for not existing groups as fallback
    • MM should not remove that pair with the missing group.
    • Maybe MM should report, so it gets fixed first. (but there are many edge cases to report...)

    (Maybe this is a case for ufonormalizer?)



  • Okay, actually, I think the solution to my problem of finding mismatches is quite simple. Here is the basis of a script I will use to detect this:

    """
        Simple script to find problems in UFO kerning, for
        https://forum.robofont.com/topic/885/metrics-machine-freezing-on-groups-update/2
    
        USAGE
    
        Run from the command line:
    
        python3 PATH/TO/SCRIPT/check-kerning-vs-groups.py PATH/TO/UFO/family-style.ufo
    """
    
    from fontParts.world import *
    import sys
    
    ufoPath = sys.argv[1]
    
    font = OpenFont(ufoPath, showInterface=False)
    
    groups = [group for group in font.groups.keys()]
    
    kerningKeyGroups = set([kern[0] for kern in font.kerning.keys() if "public.kern" in kern[0]])
    
    mismatches = [group for group in kerningKeyGroups if group not in groups]
    
    print(mismatches)
    
    


  • I should add, one simple strategy I have found to advance despite this issue is to simply apply my group changes much more frequently and save the changes. That works most of the time, and at the worst, I only lose a little bit of grouping work.


Log in to reply