-
Notifications
You must be signed in to change notification settings - Fork 14
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
Identify glif file that caused XMLSyntaxError #264
Comments
sounds good to me! Got a PR? |
Happy to put something together :) One further thought: would it better for us to wrap the XML library error here (Layer.loadGlyph) or in fonttools (GlyphSet.readGlyph)? |
If we have all the info inside fonttools, it might be better to raise it over there |
Hoolean
added a commit
to daltonmaag/fonttools
that referenced
this issue
Mar 9, 2023
This allows dependent projects to catch errors parsing glifs without requiring logic to account for which XML library fonttools is using internally (e.g. for implementing fonttools/ufoLib2#264). This commit also adds tests to ensure that the exception we expose when glifs have invalid syntax remains stable across future releases.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When ufoLib2 reads a UFO that contains a glif file with invalid XML, we do not provide enough information to identify which glif file is causing the problem.
Example
Making and then reading from a UFO with an XML error in /b:
Stack trace does not identify in which file the issue originates:
Potential change
Depending on the exceptions that dependent libraries or tools expect us to throw, we could wrap the exception to include the path to the glif file, and/or the name and layer of the glyph it represents.
This is done for other areas of the UFO, e.g. layerscontents.plist:
The text was updated successfully, but these errors were encountered: