Instance Cooker creates `ital` axis

Glyphs
1

I have some projects where I used the Instance Cooker script to generate instances in Variable Font Glyphs files. I ran into trouble with QA because I see that the script creates an ital axis, enters a {0,0} mapping in the AVAR table, and sets an Axis Location Custom Parameter with for an ital axis when using this in the recipe

#Italic:ital
0:Normal*

or

#Italic:ital
1:Italic

It is my understanding that an ital axis should not exist unless the Glyphs file contains actual interpolation between upright and italic lettershapes. However deleting the ital section from the recipe omits the ā€œItalicā€ particle of in the instance name and does not set the italic flag for them either.

Am I using it wrong?

2

Ping @mekkablue

3

Iā€™ll see what I can do. You can delete the ital axis afterwards again if it bothers you. Leaving it in there shouldnā€™t make a difference though. Because Italic is a design axis in STAT even when it is not a variation axis in fvar. The latter will only happen if you actually interpolate along the axis.

1 Like
4

Alright. So can I ā€“ to hot-fix it ā€“ manually delete the ital axis, but then keep the ital entry in the custom Axis Values parameter? Or can I delete that one too?

(As a test I deleted both the ital axis and the custom ital Axis Values parameter for both Rom & Ita, and the fonts work in browsers, but I have not done further testing so I donā€™t know where it would otherwise break.)

5

I think I fixed the script. It should now work as expected:

  • NOT create an axis in Font Info > Font > Axes
  • YES create the Axis Values entry in the VF setting in Font Info > Exports

That is the one you have to keep. It is for STAT, thus the design axis. You do not want ital in the fvar table, where the variation axes live.

That will break style linking for ital.

6

Thank you. That fixed that issue, but when I tested the instances the Bold style linking was broken in Glyphs when I have Pica as elidable, and if I do not set it to elidable then I wonā€™t have any plain ā€˜Fontnameā€™ instances, which I understand is no bueno. Generated the VF fonts, and tested them in TextEdit and Pages both with and without Pica elidable, and both did not stylelink to the corresponding Italic, but rather to the first Italic instance.

#Optical size:opsz
5>5:Micro
200>6:Minuscule
325>7:Miniature
400>8:Caption
550>12:Pica
640>16:SubHead
700>21:Trumpet
800>32:Headline
900>48:Display
980>72:Titling
1020>96:Hairline
1200>1200:Needlepoint

#Width:wdth
95>88|4:SemiCond
100>100|5:Normal*
113>113|6:SemiExp

#Weight:wght
360>360:SemiLight
400>400:Normal*
475>500:Medium
550>600:SemiBold
650>700:Bold
750>800:ExBold
900>900:Black

#Italic:ital
0:Roman*

The use of Pica is because I had a report that some applications did not understand the use of Normal in multiple axes. I then tried to change that back to Normal but that didnā€™t fix it. The style linking still jumps from Regular to Micro Italic.

Another thing is that the static instances are not linked explicitly (greyed out ā€˜Regularā€™ value or is it an example, a placeholder???)

Screenshot 2026-03-20 at 12.40.50
Screenshot 2026-03-20 at 12.40.502060Ɨ168 30.6 KB

Is that because Glyphs will do that auto-magically on export?

7

This does not surprise me. CoreText apps have lots of issues with style linking. Make sure it is correct in your STAT table and pray for a fix in Cupertino. If you submit an error report, let me know its number. Perhaps I can pinch the right people.

Once any of the checkboxes are activated, it will assume ā€˜Regularā€™ if you leave it empty. So you do not have to write it explictly.

8

[ Screams internally ]

So I tested it on Windows and their bugs were different :grinning_face:

Have a great weekend Rainer!

Variable fonts were introduced when, 2016? :upside_down_face:

9

(Connected issue so Iā€™ll put it here) Axis Values entries are not added after running either Instance Cooker or Read and Write STAT Axis Values (OTVAR) script if any Axis Values entry already exist. This feels unintended?

10
  • Read and Write will only write them once they are there, and only try to read them if they are not there. So, for this script, it is intended.
  • For Instance Cooker, it would make sense to override existing ones. Iā€™ll think about it.
11

I think a pop-up message that says ā€œYou have pre-existing Axis Values. Remove before running this script.ā€ ā€“ or something to that effect would help. That way the user is not confused thinking the script overwrote the existing fields. As it is now the script fails its task unbeknownst to the user if there are existing entries.