Skip to content
This repository has been archived by the owner on Feb 14, 2019. It is now read-only.

move designSpaceDocument to fontTools.designspace? #28

Open
anthrotype opened this issue Nov 16, 2017 · 5 comments
Open

move designSpaceDocument to fontTools.designspace? #28

anthrotype opened this issue Nov 16, 2017 · 5 comments

Comments

@anthrotype
Copy link
Contributor

Erik,
how about we move the designSpaceDocument/__init__.py module into a new fontTools.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... ;)

@anthrotype
Copy link
Contributor Author

fonttools/fonttools#911

@LettError
Copy link
Owner

  • Name: shorter might be better.
  • So to be clear we can separate the ufoProcessor module from the code that's going to fontTools? I'd prefer that because I probably need that thing more that you do. I can make it a separate package.
  • Is there a preferred way to indicate that the main repository has moved?

@anthrotype
Copy link
Contributor Author

Name: shorter might be better.

how about fontTools.designspaceLib (dsLib?) for consistency with ttLib, varLib, ufoLib, etc.?

we can separate the ufoProcessor module from the code that's going to fontTools?

yes, fontTools doesn't know about ufo (yet).

I probably need that thing more that you do

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.

Is there a preferred way to indicate that the main repository has moved?

just a big notice in bold at the top of the README, I guess

@belluzj
Copy link
Contributor

belluzj commented Nov 27, 2017

from *.glyphs to designspace + UFOs. We currently use mutatormath for that.

...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?

@behdad
Copy link

behdad commented Jan 24, 2018

This is done now. I need to review it a bit and possibly change API, but after that we can call it moved.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants