fontTools.fx — a simple aggregate subpackage to guide me through various functionalities

With the release of Volto and @anthrotype suggesting to merge it into voltLib, I’m wondering if the right way forward might be:

fontTools.fx

Make a subpackage fontTools.fx that would have relatively simple contents, and would allow to create an abstract “font exchange” object, that would in theory have the ability to:

• read and write .ttx, .ttc, .woff2, .woff, .otf, .ttf, .designspace, .ufo
• perform operations listed below in a few modules
• when something is not implemented, it could explicitly say that it’s not implemented, but sometimes might use a multi-step route, or might even — in a warning — say “do this and this to achieve it”.
• even if a given functionality is implemented, the operations could issue “caveat” warnings; the idea behind this fx subpackage is that it wouldn’t have to be perfect or production-ready, but if people start using it, they could gradually plug in the missing functionality to get rid of the warnings. So the caveats it emits could be informative (for example that some functionality, like merging, is likely to fail or has known limitations)

Before these modules are created, there could be a wiki document that shows snippets how to achieve that.

Right now, fontTools has lots of dispersed cool functionalities (which has really grown in the last 2 years), but it’s quite difficult to wrap your head around it. If you know where to look, you know where to look, but if you don’t, you don’t. 😃

fx.font

The fx.font submodule that could expose a simple unified API for the implemented methods to convert between various font formats (different packagings of SFNT such as TTF, OTF, WOFF, WOFF2, TTC in the different flavors, plus UFO).

That module could also include some methods to subset and merge, to blend and instantiate.

fx.layout

The fx.layout module could:

• expose a simple unified API for the implemented methods to convert between various storage systems for layout information (VOLT, FEA, MTI, OTL, AAT, Graphite and possibly also UFO groups+kerning). Of course not every path would be implemented initially, and some paths might never be.
• optionally, provide a uharfbuzz-based method to simulate hb-shape, i.e. actually let you perform some layout

fx.glyphs

There could also be a fx.glyphs module that could expose a simple unified API for the implemented methods to convert between various storage systems for glyph description (CFF2, CFF, glyf, sbix, CBDT, SVG, GLIF). Again, not everything would have to be implemented.

[behdad]

Maybe if this is a bit more specified, we can actually work on it.

[davelab6]

I like