Skip to content
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

Lost stylemapfamilyname entries #202

Closed
arialcrime opened this issue Apr 28, 2020 · 5 comments
Closed

Lost stylemapfamilyname entries #202

arialcrime opened this issue Apr 28, 2020 · 5 comments

Comments

@arialcrime
Copy link
Contributor

stylemapfamilyname entries defined in the .designspace files do not end up in the final variable fonts. I don’t really know why this happens but I am very eager to learn what the recommended workflow is to get them there. Or is that something that is ignored when generating a variable font?

Maybe @anthrotype knows?

@anthrotype
Copy link

anthrotype commented Apr 28, 2020

Where are you expecting them to end up in the variable font?
Then named instances in fvar only have a style name and a postscript name

@anthrotype
Copy link

anthrotype commented Apr 28, 2020

We don't modify the default name table when building a VF, that is currently inherited from the base or neutral master

@arialcrime
Copy link
Contributor Author

So this means that no naming within the designspace file is considered when building a variable font?

Using the entries from the default master does not work for the current setup of 2 designspace files, resulting in 2 variable fonts that should act as 1 in operating systems and different applications. At the moment the nameIDs of the defaults end up in places where they shouldn’t.

nameID current value desired value
1 Fraunces 144pt S100 Black Fraunces
2 Regular Regular
4 Fraunces 144pt S100 Black Fraunces
6 Fraunces-144ptS100Black Fraunces-Roman
17 144pt S100 Black Roman
nameID current value desired value
1 Fraunces 144pt S100 Black Fraunces
2 Italic Italic
4 Fraunces 144pt S100 Black Italic Fraunces Italic
6 Fraunces-144ptS100BlackItalic Fraunces-Italic
17 144pt S100 Black Italic

And of course, changing those values in the default master results in them not being called 144pt S100 Black and 144pt S100 Black Italic anymore.
Is this something that could be solved by setting openTypeNamePreferredFamilyName and openTypeNamePreferredSubfamilyName to the values mentioned in the tables?

Thanks for your help!

@anthrotype
Copy link

no naming within the designspace file is considered when building a variable font?

I'm not sure what you mean by that exactly.

So, you have a default master that has family name Fraunces 144pt S100 Black and you want the VF generate from it to have only Faunces?

it's not entirely clear to me why you would want to do that, but as I said varLib currently doesn't touch the default name table. The DS file doesn't say anything about what the various names of a VF should be. If you can make a proposal to the DS spec we can consider making those changes.

@arialcrime
Copy link
Contributor Author

no naming within the designspace file is considered when building a variable font?

I'm not sure what you mean by that exactly.

As it is explained in the designspacelib readme there are a bunch of possibilities to store naming data inside a designspace file, so I wanted to know from you if any of these would be used by ufo2ft/fontmake when generating.

So, you have a default master that has family name Fraunces 144pt S100 Black and you want the VF generate from it to have only Faunces?

Yes, correct. Mainly due to the reason that the font consists of 2 font files. 1 for Roman, 1 for Italic, which should work together, appearing as 1 family in different OS and applications. Since there is no “Regular” master, both get the name Fraunces 144pt S100 Black, which is not very representative to the content of the family.

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

No branches or pull requests

2 participants