8000 designspace with non-standard axis can't be called with varlib.main() · Issue #701 · fonttools/fonttools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

designspace with non-standard axis can't be called with varlib.main() #701

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.

Sign up for GitHub

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

Jump to bottom
Closed
LettError opened this issue Oct 12, 2016 · 8 comments
Closed

designspace with non-standard axis can't be called with varlib.main() #701

LettError opened this issue Oct 12, 2016 · 8 comments
Labels
bug

Comments

@LettError
Copy link
Collaborator
  • designspace with non-standard axis can't be called with main()
  • varlib.build() accepts an axisMap attribute which looks like it should be used to define non-standard axes.
  • but main calls build() without a map
  • line 357 defines its own standard axes

Why not just extract the axes from the designspace file?
@anthrotype anthrotype mentioned this issue Oct 12, 2016
Closed
@brawer
Copy link
Collaborator
brawer commented Oct 12, 2016

Wait for LettError/MutatorMath#57?

@LettError
Copy link
8000
Collaborator Author

Fair enough :) I'll get that going.

@behdad behdad removed the question label Oct 12, 2016
@LettError
Copy link
Collaborator Author
LettError commented Dec 5, 2016 •
edited
Loading

Following up. DesignSpace files now have a way to record the dimensions, tag and names of axes.

I have a definition of the axis element in designspace files + implemented it in the DesignSpaceDocument object.

  • Example: axis definitions in a designspace in the Adobe Variable Font Prototype: AdobeVFPrototype.designspace
  • The RoboFont extension designSpaceEditor can create and edit designspaces with axes.
  • Both DesignSpaceDocument and the editor support the axis child element labelname (discussion / code). I don't think there is any way to get this data into a font yet, right?

Also:

  • designSpaceDocument.ufo builds UFO instances. This is intended to replace the MutatorMath reader and writer eventually.
  • the values in the map element can be included.

@behdad
Copy link
Member
behdad commented Dec 29, 2016

Both DesignSpaceDocument and the editor support the axis child element labelname (discussion / code). I don't think there is any way to get this data into a font yet, right?

Yes, there is.

@typemytype typemytype mentioned this issue Jan 10, 2017
Closed
@anthrotype
Copy link
Member

I think this is now fixed after #857 #864 #865. Please reopen if this is not the case.

@anthrotype anthrotype reopened this Feb 27, 2017
@anthrotype
Copy link
Member

now that we read 'axes' from the designspace, does varLib.build still need an axisMap keyword argument? Shouldn't we deprecate that and only read from the designspace?

Also, why do we allow axisMap argument to override values from the default standard_axis_map, but instead when reading axes from designspace the standard_axis_map always take precendence?

https://github.com/fonttools/fonttools/blob/ae58d38/Lib/fontTools/varLib/__init__.py#L303-L311

@anthrotype
Copy link
Member

third question: what is that ('custom', ('xxxx', 'Custom')) entry in the standard_axis_map? Can we get rid of it?

@miguelsousa
Copy link
Collaborator

I can provide some answers since I worked on the recent changes.

  1. The <axes> element is a relatively new addition to the designspace document format. Keeping axisMap will allow older files with masters/sources whose <location> include non-standard <dimension> names to keep working.

  2. I can't speak for the handling of axisMap; I simply left it working the same way as before.
    In regards to the handling of axes, the logic is:

  • honor the order set by the designspace file;
  • consider only the axis listed in the designspace file, nothing more;
  • if a given axis in the designspace file is standard, it does not need to contain <labelname>; the label is instead sourced from standard_axis_map.
  1. Not sure what custom is used for, but can probably be deleted.
    I'll mention that there's this assert now that won't let the process go forward if master_locs references a name that is not included in axis_names.

@behdad behdad closed this as completed Apr 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@behdad @LettError @brawer @miguelsousa @anthrotype
0