The other issue about FreeType and overlaps is new and should not be confused with this one, which is about Mac OS. I wonder if alternatively the "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): 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). 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). <= El Capital 10.11, but they only produce an effect on 10.12 Sierra and greater. IIRC, from similar user reports, we concluded that these glyf overlap flags don't seem to work on older macOS versions, ie. 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. I don't feel like there is a problem with the WOFF2 filesĪs said, WOFF2 format cannot encode the glyf overlap flags, unless the glyf table is left un-transformed ( google/woff2#123). I also see that two years ago, Marc said "We could potentially solve this issue by removing overlaps on the mutated instances". If there is precisely a bug with bit 6 in old browsers, it will be a bit tricky to target those where the overlap problem can be corrected without causing the font to be rejected by OTS… So the problem only happens (normally…) with old browsers that receive non-WOFF2 files.
Normally, except for cases where the site creator used a url to get the TTF files directly (and this unfortunately looks quite common), all modern browsers receive files WOFF2 (and according to my personal and limited tests on macOS, no problem with them, with Safari, Firefox, Chrome). As it was pointed out in a comment ( fonttools/fonttools#1281 (comment)), OTS had a bug with bit 6, and this bugged version was used up to FF 59 and Chrome 63.
Probably there is a way to target browsers by platform. Especially since it's precisely to avoid a native rendering bug on macOS, if the solution leads to the use of another rendering engine, that seems a little too much.
0 kommentar(er)
