n and h right legs appearing straight instead of being diagonal

[Ph15]

Problem description
I fell in love with your font seeing the diagonal right legs of the n and h (reminding Roca).
I can see it here properly on your website when the font is in display and on Google Font, but it seems that in text format the n and h legs are both straight.

Expected behavior
I would have expected the n and h's second legs to be always diagonal, including on Google Doc, or even on your website, because it is really what I like about your font.

Screenshots
On the first two pictures (from your website and Google Fonts), the n is diagonal.
On the last two (from a Google Doc and your website), it is straight.

To Reproduce
Steps to reproduce the behavior: Create a Google Doc and use the font.

Environment (please complete the following information):

• OS: macOS 10.14.6
• Browser: Firefox 97.0.1
• Fonts: Fraunces

Additional context
Add any other context about the problem here.

[Ph15]

Hmm, very weird. After reloading the Google Fonts page, the n and h legs have become straight! And on reloading the page yet another time or typing in a new preview text, they turn diagonal!

Is this an intended behavior?
P.S.: On Canva, the font has straight legs too…

[cozysd]

🍿 👀 🤔

[kenmcd]

This appears to be an issue with the WONK axis and certain shapers.
Or it is just not configured correctly.
When the Wonk axis is On the legs are supposed to be straight.
In FontLab, the Wonk axis does not work at all - legs are always diagonal.
In FontCreator, with their default shaper the legs are always diagonal.
With their alternate shaper (which I think is HarfBuzz), the legs are always straight.
And the Wonk axis has no effect (just like in FontLab).
When opening the Google Fonts page in Vivaldi (chromium), the legs are straight, but as soon as I move the Weight axis at all - the legs jump back to diagonal.
So something is off inside the font(s).

[Ph15]

Hi everyone!
Is there anyway to solve this? (I'm not a font expert, so reading your answer @kenmcd feels like reading a foreign language 😅.)

[kenmcd]

Is there anyway to solve this?

I took another quick look today and can see the problem. It may be possible to simply yank the bad code out and it will work.
Are you going to use this on the desktop or on a website?

[Ph15]

Nice @kenmcd!

Are you going to use this on the desktop or on a website?

Both! I'm considering using it as a main font for a visual identity! 😃

[Ph15]

Hi @kenmcd!
Seems like the issue has been corrected on Google Fonts, is that so?

[kenmcd]

I do not think anything has changed on Google Fonts.
But I have looked at it more closely on web tools used by GF folks.
Such as: https://typetools.typenetwork.com/
And: https://lorp.github.io/samsa/src/samsa-gui.html
On those pages the font does appear to work in Firefox.
But I did notice that the Optical Size axis (opsz) also affects the slanted n and h.
To have the slanted alternates the opsz has to be above 21 (and the default is 9).
Open the variable font on https://typetools.typenetwork.com/
and then go back and forth between 21 and 22 opsz and you will see.
This also affects the pre-made static fonts.
The 9pt does not have the slant, and the 72 pt does have the slant.
So you may need to create some custom statics for your needs using tools like Slice, fonttools, feature freezer, etc.
So the fonts appear to be OK, just some confusion with how it operates.
I did look at modifying the variable font, but it would be quite a chore, and I think your best bet is to make statics with the specific features you want.

[Ph15]

Hi @kenmcd!
Thanks for the info! I must say I don't get all the technical details… but it seems that on Google Doc the slanted n and h remain straight. I guess I'll turn to another font for this time, and keep Fraunces for some illustration work! 😔
Hopefully one day it will be fixed! 💫
Thanks for your answers!

[davelab6]

Possibly related https://bugs.chromium.org/p/chromium/issues/detail?id=1305237

[davelab6]

I guess that the catalog shows the weight styles section with only the weight axis data, no opsz and wonk data available, and then loads the full VF with all axes for the playground section, and caches that, and then uses it for the weight styles section on second load.

You can override the auto wonk behavior with setting axis values, or by OpenType feature.

[kenmcd]

Possibly related https://bugs.chromium.org/p/chromium/issues/detail?id=1305237

Cannot see that issue even when signed-in - Permission denied.
I assume it has something to do with displaying variable fonts.

[davelab6]

I guess that the catalog shows the weight styles section with only the weight axis data, no opsz and wonk data available, and then loads the full VF with all axes for the playground section, and caches that, and then uses it for the weight styles section on second load. You can override the auto wonk behavior with setting axis values, or by OpenType feature.