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

XML syntax to define glyph and ligature substitution rules #232

Open
rimas-kudelis opened this issue Oct 2, 2024 · 6 comments
Open

XML syntax to define glyph and ligature substitution rules #232

rimas-kudelis opened this issue Oct 2, 2024 · 6 comments

Comments

@rimas-kudelis
Copy link

Ligature substitution (e.g. sub A gravecomb by Agrave) and other glyph substitution (e.g. replacing i with dotlessi when an a combining mark above follows) can currently only be defined in features.fea.

In my case, at least right now, these things are pretty much the only the only reason why I have features.fea files at all. It would be nice if there existed a more UFOy way of defining such replacements.

@alerque
Copy link

alerque commented Oct 2, 2024

Isn't this what #106 is about?

@rimas-kudelis
Copy link
Author

@alerque, see #106 (comment).

I personally don't see any merit in rewriting fea in XML. It would end up just as complicated, just as limited, just as ambiguous as it is right now (e.g. what happens if kerning instructions in kerning.plist and features.fea contradict each other?), but simply use different markup.

I assume the suggestion here would be of a much smaller scale than #106, and it would constutute a (partial) alternative to #106.

@LettError
Copy link
Contributor

Also, .fea is part of many projects that use UFO. It serves a purpose.

@rimas-kudelis
Copy link
Author

Also, .fea is part of many projects that use UFO. It serves a purpose.

And what of it? It's part of many projects precisely because UFO lacks native means to describe these features. It doesn't have to stay that way forever though.

@LettError
Copy link
Contributor

Then add it to the wish list for UFO4. There is no need to break all the projects running on UFO3 just for a perceived cleaner way of storing the data.

@rimas-kudelis
Copy link
Author

rimas-kudelis commented Oct 2, 2024

I never said I want to break any projects. I created this issue as a wish for UFO4.

But even if I expected this to be added to UFO3 somehow, I don't think the projects would break, because tools that wouldn't support this part of the spec would just keep relying on features.fea like they do now.

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

3 participants