Re: Solution to managing OpenType features as object trees?

[Sascha Brawer]

[+fonttools mailing list], perhaps someone else knows the answer

> are there any tools that you use to parse and manage .fea files through higher level objects instead of plain text?

fonttools.feaLib can parse feature files to abstract syntax trees (ASTs), and print out an AST back to feature file syntax. But I’m not aware of tools that would use this for managing feature files — if you find anything, do tell, I’d be very curious!

For Noto, we’re individually compiling script-specific shards with fontmake, and then call `fonttools merge` to merge these binary shards into a larger font; see here for the source. — For a little hobby project (a free multi-script font that supports a couple of Indic writing systems), I’m just manually combining the separate feature sources from upstream; although it’s a bit painful, it seems doable.

— Sascha

2018-02-26 15:45 GMT+01:00 梁海 <lian...@gmail.com>:

Hi Sascha,

This is Liang Hai. We had some interaction on GitHub (I wasn't very helpful though…) and birefly met once at the Unicode Conference.

I've heard that you're probably working on a project of merging a number of script-specific Noto families into a single multi-script family, which makes wonder if you have some insights about how to better manage OpenType features.

For example, are there any tools that you use to parse and manage .fea files through higher level objects instead of plain text? — I've found it's very hard to manage feature code in plain text when they have complex interactions (any changes will lead to extensive side effects on other rules), which is very common for complex scripts such as Indic ones.

(I've just noticed fontTools.feaLib seems to provide a pretty complete object system and might allow extensively manipulating feature objects trees.)

Best,

梁海 Liang Hai

http://lianghai.github.io

[Ben Kiel]

Perhaps not quite what you are looking for (it’s between text and objects, some of both), but a way of programmatically writing feature file text:

https://github.com/typesupply/feaPyFoFum

Best,

Ben

--
You received this message because you are subscribed to the Google Groups "fonttools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fonttools+...@googlegroups.com.
To post to this group, send email to font...@googlegroups.com.
Visit this group at https://groups.google.com/group/fonttools.
For more options, visit https://groups.google.com/d/optout.

[梁海]

@Sascha:

> For Noto, we’re individually compiling script-specific shards with fontmake, and then call `fonttools merge` to merge these binary shards into a larger font; see here for the source.

I see.

> For a little hobby project (a free multi-script font that supports a couple of Indic writing systems), I’m just manually combining the separate feature sources from upstream; although it’s a bit painful, it seems doable.

Yeah, actually what (in addition to my long time frustration of managing large pieces of feature code) finally led me to this pursuit of a better solution is exactly such an experience (manually combining 6 feature sources to one), but I forgot to mention.

@Ben:

Ah, a good way of thinking! I'll have a look. Thank you.

Best,

梁海 Liang Hai

[eslami...@gmail.com]

Hi Sasha,

Thank you for making this amazing feaLib. I love it! Recently I was thinking of interpreting the feaLib to find out how can I save the features inside the UFO font.lib and glyph.lib. Mostly the reason for that is I don't want to use AFDKO feature file for storing features since it's not easy to manage for complex fonts. For example, if I have lots of contextual mark positionings, I can't save it inside the glyph.anchor in UFO and feature file is also not suitable for what I want. So I need to save this data in the glyph.lib. But I don't want to convert them back to feature file again, because if I have the tables at my hand, then I can JIT compile the GPOS positionings using fontTools. So if I move a mark in the UI, I can use fontTools to get an immediate response. I decided that I should compile them from the glyph.lib directly.

This is where it gets crazy since I have to reconstruct the GPOS/GSUB data. This is how I started to make spec on how can I save this data inside the UFO. I would very much appreciate any feedback from you.

Saving scripts, languages, lookups in UFO.font.lib

This spec imposes a rule that any lookup should have a unique name, and their unique names reference them. Anything enclosed as a code is a variable; other names are fixed attributes of this interface. Scripts and Lookups are part of font lib. This is as close as it gets to the binary structure, but with enough abstraction which ensures JIT compiling it would be easy. Lookup subtables are not considered here, but they can be discussed in another topic.

• Scripts (set of Scripts):
  -- Script (dict of strings):
  ---- Tag (string): script_tag # DFLT, latn, ...
  ---- Languages (set of Languages):
  ------ Language (dict of strings):
  -------- Tag (string): language_tag # dflt, FAR, ...
  -------- LookupList (list of strings): [lookup_name, ...] # any unicode string

• Lookups (set of Lookups):
  -- Lookup (dict of strings):
  ---- Name (string): lookup_name # any unicode string
  ---- Type (string): lookup_type # SingleSubst, LigatureSubst
  ---- Flags (set of strings): [lookup_flag, ...] # IgnoreMark, ...
  ---- Features (set of strings): [feature_tag, ...] # liga, ...

Complier sorts ScriptSet and LanguageSet alphabetically based on their tags. Order of lookups is designed in the Language.LookupList by the user.