-
Notifications
You must be signed in to change notification settings - Fork 9
move designSpaceDocument to fontTools.designspace? #28
Comments
|
how about
yes, fontTools doesn't know about ufo (yet).
also we would like something like that -- for example in glyphsLib where we convert from *.glyphs to designspace + UFOs. We currently use mutatormath for that.
just a big notice in bold at the top of the README, I guess |
...and we're moving to use designspaceDocument instead, as done in the roundtrip PR. So a class like ufoProcessor would probably be useful to glyphsLib in the near future. I have currently written a very thin subclass of DesignSpaceDocument to allow keeping a reference to an in-memory defcon.Font instead of a pathname in SourceDescriptor, and I will soon have to add functionality similar to ufoProcessor. Maybe once the move to fonttools is done for the basic DesignSpaceDocument, we can discuss the glyphsLib usecase for something like ufoProcessor, and if we find that it's a generic enough use-case, we could put the supporting class into fonttools as well? |
This is done now. I need to review it a bit and possibly change API, but after that we can call it moved. |
Erik,
how about we move the
designSpaceDocument/__init__.py
module into a newfontTools.designspace
module (or if you prefer camelCalse,fontTools.designSpaceDocument
)?Only the generic part, not the ufo specific one (for now at least, until we also have a
fontTools.ufoLib
).You'll still be the benevolent dictator of course... ;)
The text was updated successfully, but these errors were encountered: