Inter – Capital 'A' not showing correctly on Mac OS

[topherboulevard]

The capital 'A' isn't displaying correctly. I've researched the issue further and it seems that it displays fine on Chrome on Windows 10, but not Mac OS.

I'm using Chrome on macOS Catalina, version 10.15.6 and the font was downloaded form Google.

I've since downloaded the latest version from rsms.me/inter and it's working fine so it must be a bug at Google's end.

[thundernixon]

How was it displaying, and was it only under some conditions, or all? Can you please include a screenshot? Thanks!

[topherboulevard]

It was showing like this and all the time.

…

On Wed, 12 Aug 2020, 04:23 Stephen Nixon, ***@***.***> wrote: How was it displaying, and was it only under some conditions, or all? Can you please include a screenshot? Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOCAU4QMTWZXERLC7RMQETDSAIDMNANCNFSM4PVMPHYA> .

[topherboulevard]

[saharob]

@thundernixon
here is a screenshot of capital A on Mac
https://ibb.co/PGWjG1r

[zvuc]

Screenshot of A and other affected glyphs.
Loading Inter font thru Google Fonts (CSS) @import url('https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');

macOS Catalina, Firefox / Chrome

[dpkonofa]

This issue is showing up on macOS Catalina 10.15.6 with Firefox 80.0.1 as well with the Mulish font.

[thlinard]

I can't reproduce with Firefox 80.0.1, Safari 13.1.2 and Chrome 85.0.4183.102 on MacOS 10.15.6 with

• https://fonts.google.com/specimen/Inter
• https://fonts.google.com/specimen/Mulish

[dpkonofa]

@thlinard - The issue doesn't occur on the Google pages. It only occurs on pages that load the fonts from the Google CDN.

That being said, I just tried to duplicate in a CodePen and am not getting the issue in the same Firefox browser.

[dpkonofa]

Here's a CodePen that I was able to whip up that exhibits this issue: https://codepen.io/derekkgilbert/pen/RwaJYQg

Edit: Tested the CodePen on BrowserStack and am able to reproduce the issue on multiple browsers, all on macOS.

[thlinard]

Oh! OK, you're using the unsupported "https://fonts.gstatic.com/…" url.

At least we see the problem is with TTF format fonts (using the official url given at https://fonts.google.com/specimen/Mulish, i.e. "https: // fonts.googleapis.com/css2?family=Mulish… ", Safari receives files in WOFF2 format, not TTF).

[dpkonofa]

Is that the case for Firefox also? If we fix that URL, should the problem resolve?

[thlinard]

Well, I guess if you find and use the "https://fonts.gstatic.com/…" url which gives WOFF2 files, the problem goes away, yes.

But there is a reason why these gstatic urls are not supported: the "https://fonts.googleapis.com/css2…" url (the one you find on https://fonts.google.com) allows to serve files different browsers (the format of the file, unlike the gstatic urls, is not determined: this will be chosen by Google's servers depending on the browser), and it's a bad idea to serve TTF files to a modern browser, but the reverse is also true: serving WOFF2 files to an older browser may not work.

TLDR: the "https://fonts.googleapis.com/css2…" url is the one to use.

[dpkonofa]

Set up some CodePen forks and sent to our devs. You're totally right. It works with the proper import.

Thanks for helping troubleshoot.

[nikparo]

We have seen this issue as well, specifically with .woff files. (If I'm not mistaken, it's woff files converted from variable woff2 fonts that exhibit this issue) While it would be great if everyone used modern browsers that supported woff2 fonts, that is not always the case. At least some of our customers, and their customers, still use IE.

[thlinard]

Of course the problem is not solved . But we can narrow its definition: the source is not a problem with old versions of macOS (like @behdad says in his comment of issue #2666). This is a problem with non-WOFF2 files, so probably with the process of creating the files by Google.

@m4rc1e? @davelab6? I don't know if @thundernixon still follows the thread.

Probably related (if I assume correctly WOFF2 = VF, other formats = statics) to issue #2616.

[behdad]

We need people who know about this to chime in. @Lorp @anthrotype @drott

[heymartinadams]

Maybe also https://github.com/rsms

[Lorp]

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

[thlinard]

Hi @Lorp thanks, very interesting!

I don't feel like there is a problem with the WOFF2 files, so no need to leave the glyf table untransformed.

For the other formats, I don't know the creation process used by Google (but I assume it's based on fonttools and varLib), but this process would have to add bit 6 on static fonts.

There are two drawbacks:

1. As you point out, if it means forcing a quadrupling of rendering time by FreeType, it loses some of its interest. Especially since it's precisely to avoid a native rendering bug on macOS, if the solution creates another issue with another rendering engine, it's not good. Probably there is a way to target browsers by platform.
2. As it was pointed out in a comment ([varLib.mutator] Overlapping contours on old versions of Safari fonttools/fonttools#1281 (comment)), OTS had a bug with bit 6, and this bugged version was used up to FF 59 and Chrome 63. Normally, except for cases where the site creator used a https://fonts.gstatic.com/ 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). So the problem only happens (normally…) with old browsers that receive non-WOFF2 files. 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…

I also see that two years ago, Marc said "We could potentially solve this issue by removing overlaps on the mutated instances". It may be preferable.

Or add your dummy fvar table. 😉

[apodtele]

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.

[apodtele]

That bar in 'A', does it have correct orientation? If it is wrong, the white is white regardless of the fill rule.

[anthrotype]

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.

[thlinard]

That bar in 'A', does it have correct orientation? If it is wrong, the white is white regardless of the fill rule.

Seems OK: https://fonts.gstatic.com/s/mulish/v1/1Ptyg83HX_SGhgqO0yLcmjzUAuWexXRWwaA.ttf

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.

Well, I presume in this case these files don't need a dummy fvar table: they are legit VF files, and interpreted as such (and the absence of bit 6 is then irrelevant).

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.

I see there are two TTF versions, one showing the problem:
https://fonts.gstatic.com/s/mulish/v1/1Ptyg83HX_SGhgqO0yLcmjzUAuWexXRWwaA.ttf
and the other not (with bit 6 enabled):
http://fonts.gstatic.com/s/mulish/v1/1Ptyg83HX_SGhgqO0yLcmjzUAuWexXRWwaClGrw-PTY.ttf

Indeed, maybe the distribution of these "xxxClGxxx-PTY" files is too restricted? (But, like I said earlier, some site creators seems to use https://fonts.gstatic.com/ url directly, and maybe that is the real origin of all these bug reports — since until now all affected people reported using recent macOS and the latest versions of browsers.)

[m4rc1e]

Apologies for the late reply, I was on holiday.

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.

@anthrotype, If I fetch Jost-Italic (family has the same issue) which we serve to OSX 10.11 (El Capitan) on Safari 9.1, I get the following array for the flags for the "A" glyf.

>>> f['glyf']["A"].flags
array('B', [65, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1])

Bit 6 has been enabled for first node which happens to be the starting node of the crossbar. I assume we only need to enable this bit for a single node in order for it to work?

If I check the font in OS X 10.11 (El Capitan) on Safari 9.1, the issue is present.

Since the bit is enabled and assuming we only need to enable it for a single point, it's clear that this browser is ignoring bit 6. Since no amount of bit twiddling will solve this issue, we could remove the overlaps for static fonts sent to OS X. Since these fonts don't require hinting, I don't see it being a problem.

For those wanting to replicate this experiment, here's the cmd I used to fetch Jost-Italic that we serve to OS X 10.11 Safar 9.1:

wget https://fonts.gstatic.com/s/jost/v3/92zJtBhPNqw73oHH7BbQp4-B6XlrZu0EBIokmNPOIEtWCw.woff

[brightgirl]

I'm seeing this issue with Montserrat and Comfortaa fonts on MacOS 10.14.6 Mojave in Chrome 97.0.4692.71, Safari 12.1.2, and Firefox 96.0. Also observed on another Mac running Catalina with the latest version of Chrome.

[kwcooper]

Adding another datapoint if it somehow helps with debugging...
MacOS Catalina 10.15.6
Chrome 97.0.4692.71

But, funny enough, it displays fine on the Google slides app on my iPad

[davelab6]

10.14.6 was released September 2018; since this is a problem with the way the OS' font rendering system renders valid variable fonts, I think its unlikely to ever be fixed.

[WONDARUK]

I had the same issue on a website project. This is gonna work. Use one of these for each font-weight:

/* cyrillic-ext 300*/
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 300;
src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUSjIg1_i6t8kCHKm459WRhyzbi.woff2) format('woff2');
unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
}
/* cyrillic /
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 300;
src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUSjIg1_i6t8kCHKm459W1hyzbi.woff2) format('woff2');
unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
}
/ vietnamese /
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 300;
src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUSjIg1_i6t8kCHKm459WZhyzbi.woff2) format('woff2');
unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+1EA0-1EF9, U+20AB;
}
/ latin-ext /
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 300;
src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUSjIg1_i6t8kCHKm459Wdhyzbi.woff2) format('woff2');
unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/ latin */
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-weight: 300;
src: url(https://fonts.gstatic.com/s/montserrat/v21/JTUSjIg1_i6t8kCHKm459Wlhyw.woff2) format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

[JayHoltslander]

Subscribing as I am also having this issue.
Fonts in question: Jost and Montserrat on two different sites.
One site, local hosted font files, the other site, Google hosted.

[lularocha]

Hi, folks
I'm not an expert but apparently if you store the fonts on your server, it fixes the problem.
On one of my websites with WordPress + Kalium Theme, I was having the same problem:
The font "Red Hat Text" from Google capital letter A showing cutouts on overlaps).
But the Kalium Theme has this option to "Pull Google Fonts" (see attachments) and after I turned that on the problem went away.
Hope this is helpful.

(Using Chrome Version 100.0.4896.75 (Official Build) (x86_64) + MacOS Catalina 10.15.7)

[amarineau]

I've got the same issue with Inter Font download locally.

I download the package from google font and the font is bugged. If i use the import css method it's work fine.

Any solution ? ( i need to use this font locally )

[linuxonrails]

@amarineau

Same problem here! ✋

At the moment I am using the official version downloaded from https://rsms.me/inter/ (include CSS to serve the files locally).
But it is not the most optimal solution.

[amarineau]

Oh can be usefull to know that thx !

Yes, i do with the import CSS method currently. We will wait for a right solution.

[Anticosti]

The solution for me has been to download Montserrat font from Squirrel and then convert the files to woff and woff2.

[weiseger]

@Anticosti: this was a perfect workaround for me. Thank you!
I suspect Google to do this on purpose. I will use Font Squirrel exclusively in the future

[pi-jobayashi]

Hi all, thank you for commenting and testing this issue - it was bugging me during an email development project.

Here’s something I found that fixed the issue for the email build: when loading Inter via a tag, the ampersand (&) needs to be written out as the HTML entity (&).

For example, instead of this:
<link href="https://fonts.googleapis.com/css2?family=Inter&display=swap" rel="stylesheet">

Try this:
<link href="https://fonts.googleapis.com/css2?family=Inter&amp;display=swap" rel="stylesheet">

Hope that helps!

[RobRoyBoy]

First i love this font!

During a web project i have the same issues as describe below.

On windows systems and anroid devices it still look fine. But the nasty thing is, on some Mac IOS and Os systems (macOS Monterey Ver. 12.6) the issues are still there. For me i have solve the issue with the inter font

Solution:

1. Don´t use the inter font from google.

2. Download the font form the original source.

   https://github.com/rsms/inter/releases/tag/v3.19

3. convert the font otf to WOFF, WOFF2 ... etc
   (i don`t check if the WOFF, WOFF2 format form the original source is working. May be it is
   too long ago to remember ;-) )

   Web tool to convert
   https://transfonter.org/

Before you are going to use the Font, use this CSS property in your Developer tools

-webkit-text-stroke: 1.52px #75ff25;
-webkit-text-fill-color: #0000;

to check If there some overlapping issues*.

The font have to be look like this with no overlapping Lines:

also have a look at my web presence

www.vier-raum.de (here i am using the the inter)

• If there some overlapping.

Don´t use the font If there overlapping issues

Example of overlapping issues:

https://fonts.google.com/specimen/Inter?preview.text=A4&preview.text_type=custom&query=inter

https://rsms.me/inter/lab/?antialias=default&size=148&wght=779

Hopefully i could help you so far.