search

unified-font-object / ufo-spec

The official Unified Font Object specification source files.
http://unifiedfontobject.org
175 stars 30 forks source link

XML syntax to define glyph and ligature substitution rules #232

Open rimas-kudelis opened 1 month ago

rimas-kudelis commented 1 month ago

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 commented 1 month ago

Isn't this what #106 is about?

rimas-kudelis commented 1 month ago

@alerque, see https://github.com/unified-font-object/ufo-spec/issues/106#issuecomment-2387661002.

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 commented 1 month ago

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

rimas-kudelis commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.