Skip to content
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

Closed
brawer opened this issue Nov 13, 2017 · 9 comments
Closed

ufo2ft generates invalid output when glyph name starts in # #175

brawer opened this issue Nov 13, 2017 · 9 comments

Comments

@brawer
Copy link
Contributor

brawer commented Nov 13, 2017

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:

markClass _Qtail <anchor 183 79> @MC_#Qtail;

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.

@anthrotype
Copy link
Member

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.
Yes, ufo2ft should avoid creating invalid features by stripping or escaping those invalid chars in anchor names, but that still doesn’t match Glyphsapp behaviour.

@adrientetar
Copy link
Collaborator

in Glyphs.app

That should be handled in glyphslib, no?

@moyogo
Copy link
Collaborator

moyogo commented Nov 13, 2017

in Glyphs.app

That should be handled in glyphslib, no?

If one wants to roundtrip between UFOs and a Glyphs file, no.

@anthrotype
Copy link
Member

https://glyphsapp.com/blog/new-features-in-glyphs-2-3 -> "State of Component Alignment" says "If, however, you want to prevent Glyphs from generating the positioning code, you can now prefix the anchor name with a non-letter"

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.
Even the "_" underscore prefix convention for attaching anchors is unofficial yet widely used.
Of course, I'd like to know more about how exactly this works in Glyphs.app. Based on that blog post, any anchor whose name start with a non-letter (even a digit?) should not be included in the mark/mkmk feature code. Am I correct, @schriftgestalt?

Would you guys see any issues if ufo2ft mark feature writer did the same by default?

@khaledhosny
Copy link
Collaborator

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).

@adrientetar
Copy link
Collaborator

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.

@anthrotype
Copy link
Member

As I said the underscore thing is not in the UFO spec either

@adrientetar
Copy link
Collaborator

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.

@khaledhosny
Copy link
Collaborator

Fixed in #869

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants