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

fvar.instances returns empty name entry if nameID is 17 (preferredSubfamily) #687

Closed
eweracs opened this issue Mar 20, 2024 · 13 comments · Fixed by #694
Closed

fvar.instances returns empty name entry if nameID is 17 (preferredSubfamily) #687

eweracs opened this issue Mar 20, 2024 · 13 comments · Fixed by #694
Labels

Comments

@eweracs
Copy link

eweracs commented Mar 20, 2024

In the name table, the preferredSubfamily name is set in nameID 17. In exports from the Glyphs font editor, the fvar table references this entry for the default variable font instance. However, opentype.js returns an empty name entry for this instance when listing the fvar instances.

Expected Behavior

fvar.instances should return a name entry for the default instance (which often has nameID 17 as its corresponding name entry).

Current Behavior

Currently, fvar.instances returns, for example, {"name":{},"coordinates":{"wght":100,"ital":0}} if the nameID for that fvar instance is 17.

Possible Solution

I assume the nameID 17 is, at some point, automatically replaced by a "preferredSubfamily" identifier, thus returning undefined when being searched for in the name table. This should not be done. The name IDs should be read as they are from the fvar table and then referenced in the name table.

Steps to Reproduce (for bugs)

Export a variable font from the latest Glyphs version and check its fvar instances. Alternatively, get a variable font trial from abcdinamo.com (for example), such as Arizona, and check its fvar instances.

Context

I have been trying to list all instance names of a variable font, by getting the name table entries from the fvar instance list. However, I get an empty entry for the name of the default instance.

Your Environment

  • Version used: 1.3.4
  • Font used: Arizona Serif Variable
  • Browser Name and version: irrelevant
  • Operating System and version (desktop or mobile): irrelevant
  • Link to your project: irrelevant
@owenhoskins
Copy link

owenhoskins commented Mar 26, 2024

We're having this exact problem as of Glyphs 3.1.2, thanks for posting the issue @eweracs

@eweracs
Copy link
Author

eweracs commented Mar 26, 2024

as of Glyphs 1.3.2

@owenhoskins Are you sure about this? Do you mean Glyphs 3.2 or Glyphs 1.3.2? Can you post the exact build number in the bottom left at Glyphs > About Glyphs? It's the one in parantheses.

@owenhoskins
Copy link

Typo thanks @eweracs - Glyphs 3.1.2 (3151) and Glyphs 3.2 (3245)

@Connum
Copy link
Contributor

Connum commented Mar 27, 2024

After a very quick lock, I think it could be related to this comment in the code

// we have to handle fvar before name, because it may modify name IDs
but we'll have to investigate further.

So the issue was introduced with a specific update of our library in your software? Can you tell us the specific commits that were used in the version that introduced the issue and the one before?

@eweracs
Copy link
Author

eweracs commented Mar 27, 2024

Hello @Connum, thanks for looking into this. That does indeed look like the issue.

The issue was not necessarily introduced with a specific version of the Glyphs font editor, it just so happens that Glyphs doesn't add a separate name table entry for the default instance but simply references ID 17 (preferredSubfamily), since the default instance and preferredSubfamily are supposed to be identical as per the variable font spec.

In Kürze: It looks like opentype.js searches for the key preferredSubfamily (but I may be wrong in my quick read of the code). It should, instead, search for the key 17. So the fvar table needs to be handled before name, just as your comment suggests.

A fix for this would be most appreciated, I have a project depending on this which means it currently necessitates quite an extensive workaround. Thanks!

@Connum
Copy link
Contributor

Connum commented Mar 27, 2024

Alright, I will look into this once I finish my current WIP with COLR/CPAL rendering, hopefully tonight or tomorrow.

BTW, would Glyphs be interested in sponsoring (and therefore speeding up) opentype.js development? (see #622)

@eweracs
Copy link
Author

eweracs commented Mar 27, 2024

Thanks a lot! I can't speak on Glyphs' behalf, I'm not associated with Glyphs. In terms of sponsoring, a sponsoring from Google's side would surely make sense. But I'm veering off-topic.

@ILOVEPIE
Copy link
Contributor

@Connum Ill see if I can get a google summer of code sponsorship or something to work on opentype.js, The main thing holding me back is the bad job I currently have, a sponsorship would enable me to work on this dedicated.

@Connum
Copy link
Contributor

Connum commented Apr 3, 2024

I'm taking a look at this right now. @eweracs Could you provide a very basic test font (needs nothing that doesn't help reproduce this issue) that we can include for our test cases?

@eweracs
Copy link
Author

eweracs commented Apr 3, 2024

Many thanks. I'm not at my computer right now, but I will prepare one in a bit.

@eweracs
Copy link
Author

eweracs commented Apr 3, 2024

Here is one:

VARTest.ttf.zip

You will find that the fvar table is reported to contain an unnamed instance, the default instance (with nameID 17).

@Connum
Copy link
Contributor

Connum commented Apr 3, 2024

Will be fixed via #694.

@eweracs
Copy link
Author

eweracs commented Apr 3, 2024

Brilliant! Thank you!

Connum added a commit that referenced this issue Apr 11, 2024
* fix fvar axis/instance name parsing and writing (fix #687)

* fix unsupported tables disrupting the writing process
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants