-
Notifications
You must be signed in to change notification settings - Fork 43
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
ufo2ft generates invalid output when glyph name starts in # #175
Comments
It’s not that simple, because in Glyphs.app the meaning of those leading non-letter characters in the anchor names is actually to not output any glyph positioning rules for those. |
That should be handled in glyphslib, no? |
If one wants to roundtrip between UFOs and a Glyphs file, no. |
I would not be against adding support for such a feature in ufo2ft mark feature writer, if that could be useful for UFO-only projects as well. Would you guys see any issues if ufo2ft mark feature writer did the same by default? |
I don’t mind such a behavior myself, but I also think documenting all the anchor naming conversions used by ufo2ft is well due (since we apparently are not going to get robust anchor type support in UFO anytime soon). |
I don't personally mind this in practice, but I wish it was put in the specification since it's going to change compiler behavior for existing UFOs. |
As I said the underscore thing is not in the UFO spec either |
yea I think the same of it. I don't oppose going ahead with # right now, but we ought to put it in the standard otherwise it's gonna be like C compilers where each does mostly the same thing but has differences or specific syntax meaning the same file produces different results. |
Fixed in #869 |
When a font contains glyphs whose names start with a
#
, e.g.#Qtail
, ufo2ft should escape the#
in its output. Currently, ufo2ft copies the string into its output without escaping, which leads to syntactically malformed feature files like this:In feature file syntax, the
#
character starts a comment, so feaLib (and also any other feature files compiler) will choke on the output. See fonttools/fonttools#1100 and googlefonts/fontmake#347.The text was updated successfully, but these errors were encountered: