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
1. designspace geometry
6. font info
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.
designspaceProblems.DesignSpaceChecker can either read a path or accept a working
ufoProcessor.DesignSpaceProcessor object. Tests and example code in
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