Structured problems for designspaces

If we have different libraries looking at interpolating systems such as designspaces, it makes sense to have a shared vocabulary for the types of problems that can occur. This data generally is very diverse, font info, kerning info, all the glyph geometry and so on and it comes from different sources. Often edited by different people as well. So improved reporting of problems can help in improving interoperation between tools that edit, validate and generate.

This list of problems is probably not complete and perhaps not granular enough. But the numbering system allows for many more problems to be added. The problems are roughly organised from big to small. The problem objects are not python error objects.

designspace problem categories

• 0. file
• 1. designspace geometry
• 2. sources
• 3. instances
• 4. glyphs
• 5. kerning
• 6. font info
• 7. rules

Categories 0, 1, 2 are structural: these problems need to be solved before anything else can happen. Categories 3, 4, 5, 6, 7 need access to the fonts, so before loading you could check if it is necessary.

DesignSpaceChecker

The designspaceProblems.DesignSpaceChecker can either read a path or accept a working ufoProcessor.DesignSpaceProcessor object. Tests and example code in /tests/makeTests.py

  dc = DesignSpaceChecker(designspacePath)
  dc.checkEverything()
  
  # now all problems are stored in dc.problems
  pprint(dc.problems)
  
  # convenience method that checks of the space has
  # problems of categories 0,1,2
  assert not dc.hasStructuralProblems()   # minimum working designspace, ready for fonts
  
  # you can also test for specific issues like so:
  assert (4,7) in dc.problems # default glyph is empty, glyphName

All the probs

The full lists of problems is generated by designspaceProblems.problems.makeErrorDocumentationTable() and is problems.md