I’m experimenting with exporting a variable font from a current project. I’ve set up a weight axis and an optical size axis. The Glyphs file has four masters, a regular and bold text cut both set to optical size 12, an a regular and bold display cut both set to optical size 48.
Everything seems to be working except when testing with sliders (for example in Axis Praxis or the mekkablue fonttest) when optical size is at the minimum of 12 the display variant is appearing. As soon as I move the slider to 13 it jumps to the proper text cut, and as it slides up to 48 everything progresses as expected. It’s just at the starting point of 12, it’s actually showing me the other extreme of the axis.
Is the design space properly rectangular?
Yes masters are at 105,12; 205,12; 105,48; and 205,48.
The error happens no matter where the weight slider is.
I believe I got into some trouble similar to what you’re describing when I didn’t have the numbers in my instances properly coordinated with those in my masters. I’m not sure I’m remembering exactly, but I think some of the numbers in my instances may have been out of range. So that’s one thing to check.
Your weight numbers look unusual. Why not use the standard numbers–300 for light, 700 for bold, etc. as in the Font Info → Instance panel? The recommendation for the Optical Size axis is to use point sizes. Is 12 really the smallest size you’re designing for?
Microsoft’s OpenType specification pages are a huge help when laying out your axes:
1 Like
My weight numbers are based on stem width, which the tutorial suggests should work. And I’ve drawn my text masters with a target size of 12 points so that’s where I set them. Maybe I’ll eventually have to extrapolate or draw an optically smaller master at some point. But at any rate, the set instances all fall within 105-205 and 12-48.
I do have parameters on all the instances that scale to UPM 1000 (It’s drawn at 1100.) And the display cut instances have parameters that change their familyName (to append “Display”). Would those parameters be the source of the error?
The more I think about it the more I wonder if that font name parameter is the culprit.
I set up the font (originally just to export separate instances, not as a variable font) with eight instances:
- Fontname
- Fontname semibold
- Fontname bold
- Fontname black
- Fontname Display
- Fontname Display semibold
- Fontname Display bold
- Fontname Display black
Those last four were set up by having the familyName parameter set to “Fontname Display”. That seemed to me a practical way of having the font appear in menus (four styles each of two menu entries, instead of eight styles under one entry).
But what that does mean is that both Fontname (regular) and Fontname Display (regular) have identical Style Names, so maybe that’s causing confusion. I do note that the test page at https://dinamodarkroom.com only shows four instances to choose from, and the test page at Axis Praxis shows eight but the cuts are not distinguished by name (that is, the list of options is Regular (default), Semibold, Bold, Black, Regular, Semibold, Bold, Black).
They look right to me (but capitalize Bold, etc?)
I honestly don’t know if this would make a difference, but have you set “Elidable STAT Axis Value Name” parameters?
Yes, the lowercase was just lazy typing on the forum, in the font they are capitalized. And no, haven’t used that elidable name parameter anywhere.
Well, after reviewing the tutorial on naming, I rearranged the naming so that “Display” went into the style name rather than being added to a parameter-replaced family name, and added parameters for WWS names.
The good news is that solved the problem of the instances not showing up at those test sites.
The bad news is it didn’t solve the glitchy optical size extreme issue.
Can you send me the .glyphs file?
sent to support
I had a look the file and can’t find the problem. When you rename the axis, it works just fine.
@eliason is this on Safari by any chance? I’ve noticed that the extreme end of the optical axis resets like that on Safari (but not on Chrome for instance).
1 Like
Aha! Yes, the problem appears on Safari but not on Chrome! So a Safari bug rather than a Glyphs bug?
The files from Glyphs are fine, you can compare them with ttx. There is no special treatment for axis.
I remember talking to Nick Sherman about this some time ago and he said:
I noticed the font suffers the same issue in Safari as a few other variable fonts I’ve seen: when maxing out the optical size axis, the design seems to snap down to the lowest value. I believe this is technically an issue with Safari and not your font, but there may be a way to prevent it …
For me it was a Safari bug and nothing to do with the font but it would interesting to find if there are fonts with an optical axis on https://v-fonts.com that don’t have that problem. Still, I don’t expect this to be a Glyphs bug.