montserrat-v24-latin - bug with "A" ?

[Anticosti]

I am just wondering if this is a known bug with the capital "A" when using Monserrat v24 ? It looks like horizontal bar joining with the obliques has a problem... Curiously, only on desktop... hmmmm...

If i swap monserrat-v24 for raleway-v27 all is fine:

[k1sul1]

Same thing with nordics, Ä doesn't work. Same issue. I'm running v23, so it's definitely been a problem for a while.

[linuxonrails]

https://github.com/google/fonts/issues/2602

[xpe]

As mentioned by @linuxonrails above, the bug report at https://github.com/google/fonts/issues/2602 seems relevant.

I want to highlight what appear to my eye as the key hypothesis to consider:

"bit 6 for any glyph that contains overlaps"

This is a problem with non-WOFF2 files

@thlinard it’s a problem for any TTF that has been decompressed from a WOFF2 file.

The issue can be fixed in static TTF by setting bit 6 for any glyph that contains overlaps. It’s harmless for other glyphs, but may force rasterizers down a slow path: @apodtele reports “quadrupling of rendering time in FreeType” googlefonts/ufo2ft#402 (comment)

Unfortunately standard woff2 compression strips out bit 6, though woff2 creation tools allow you to use less optimzed compression that preserves the bits, e.g. fonttools ttLib.woff2 compress --no-glyf-transform

Variable fonts don’t need bit 6.

More info:

• woff2_compress zeroes the glyf OVERLAP_SIMPLE flag woff2#123
• googlefonts/ufo2ft/issues/402#issuecomment-692841323

"confusion about OVERLAP_SIMPLE and OVERLAP_COMPOUND"

Apple always specified that TrueType is supposed to use non-zero fill rule. The even-odd fill that you see is out-of-spec buggy behavior. It is Type1/CFF fonts that were specified to use the even-odd rule. See also FT_OUTLINE_EVEN_ODD_FILL. The even-odd fill is not an artifact, it is a design feature in PostScript rendering and a bug in TrueType rendering.

So let's clear this confusion about OVERLAP_SIMPLE and OVERLAP_COMPOUND that, as names, suggest, just flag overlaps and have nothing to do with the fill rule . The inflated coverage at the overlap intersection is an artifact indeed that FreeType can only mitigate through 4x4 oversampling. For that FreeType will introduce FT_OUTLINE_OVERLAP in the next version. At the moment FreeType it is only inherited from explicit OVERLAP_SIMPLE or OVERLAP_COMPOUND.

"these glyf overlap flags don't seem to work on older macOS versions"

I don't feel like there is a problem with the WOFF2 files

As @Lorp said, WOFF2 format cannot encode the glyf overlap flags, unless the glyf table is left un-transformed (google/woff2#123). If you inspect the font files imported from the Google Fonts API you'll notice that for macOS we serve WOFF 1.0 instead of WOFF2, so that those flags can be retained.

IIRC, from similar user reports, we concluded that these glyf overlap flags don't seem to work on older macOS versions, ie. <= El Capital 10.11, but they only produce an effect on 10.12 Sierra and greater. Perhaps @m4rc1e could confirm this.

So for this relative minority of users they may still see the white cutouts, despite the glyf overlap flags are set (and not lost in transit). The only thing that would work in this case is removing the overlaps at the time we generate the instances (and we're considering whether to do that).

I wonder if alternatively the @Lorp's "fvar hack" (that tricks the renderer into thinking the static font is variable, thus forcing nonzero fill) could also help fixing this issue even on older Mac OS that don't read the overlap flags (I haven't tried yet): googlefonts/ufo2ft#402 (comment)

The other issue about FreeType and overlaps is new and should not be confused with this one, which is about Mac OS.

[xpe]

In any case, given the complexity above, it seems prudent to close this issue under the (fair?) assumption that upstream sources are best positioned to handle these kinds of complex bugs.