8000 [varLib] Accept DesignspaceDocument objects in build() and load_designspace() by madig · Pull Request #1416 · fonttools/fonttools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[varLib] Accept DesignspaceDocument objects in build() and load_designspace() #1416

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from
Closed

[varLib] Accept DesignspaceDocument objects in build() and load_designspace() #1416

wants to merge 5 commits into from

Conversation

madig
Copy link
Collaborator
@madig madig commented Dec 19, 2018

We need a way to integrate sparse masters that come from ("brace") layers instead of stand-alone sparse UFOs. Instead of modifying varLib.build() and MasterFinder to go look for specially named files like in #1387, modify varLib.build() to take either

  1. a path and continue as before (masters from layers not supported then, unless you write the compiled TTFonts to disk and refer to them with the filename attribute and probably adjust master_finder)
  2. or a DesignspaceDocument and demand that the caller already read and attached the TTFont objects to all SourceDescriptor.font attributes. ufo2ft will do this when calling https://github.com/googlei18n/ufo2ft/pull/300/files#diff-cd32d8abceb8eff27b2b4994f7322bc1R256.

@behdad
Copy link
Member
behdad commented Dec 19, 2018

Sgtm.

@madig
Copy link
Collaborator Author
madig commented Dec 19, 2018

After a discussion with Cosimo, we want to support three use cases:

  1. The CLI should continue to work as before, as in python3 -m varLib my.designspace --master-finder "somewhere/{stem}.otf". Usually, the pointed to Designspace file contains UFO sources, so we need to go find the master binaries.
  2. In-memory merging without intermediate writing to disk must be possible, so build() must be able to take a DesignspaceDocument where the SourceDescriptor.font attributes have been either partially or fully preloaded by e.g. fontmake/ufo2ft.
  3. It should be possible to fontmake -m my.designspace -o ttf-interpolatable --output-path somewhere && python3 -m varLib somewhere/my.designspace, i.e. to write a Designspace file where the SourceDescriptor.filenames point to OT binaries. In that case, there must be no layerName as that doesn't make sense for OT binaries and the master finder should not be invoked.

It's a bit unfortunate that build() takes a file path instead of expecting a fully loaded DesignspaceDocument and letting the caller care about the nitty-gritty...

@anthrotype
Copy link
Member

@madig nice write-up, thanks 👍

@readroberts
Copy link
Collaborator

This is a useful idea, if I understand it correctly, even without brace layers. I am currently dealing with a workflow where all the source fonts will have a full glyph complement, and I will have to subset some of them to temporary files to make sparse source fonts. With this PR, I think i can read in the original source fonts and attach the TTFont objects to the DesignSpace SourceDescriptor.font attributes, and subset them in memory.

@anthrotype
Copy link
Member

@readroberts correct

@behdad
Copy link
Member
behdad commented Dec 20, 2018

It's a bit unfortunate that build() takes a file path instead of expecting a fully loaded DesignspaceDocument and letting the caller care about the nitty-gritty...

Change it as you wish.

@madig
Copy link
Collaborator Author
madig commented Dec 20, 2018

Changing it might be something for 4.0. I'd like to think more on the API. Maybe we can move MasterFinder to the entry points instead of having them in __init__...

@anthrotype
Copy link
Member

@madig merged manually to https://github.com/fonttools/fonttools/tree/varlib-build-accept-ds-object branch, let's continue there

@anthrotype anthrotype closed this Dec 20, 2018
@madig madig deleted the varlib-build-accept-ds-object branch December 20, 2018 11:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0