-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inter – Capital 'A' not showing correctly on Mac OS #2602
Comments
How was it displaying, and was it only under some conditions, or all? Can you please include a screenshot? Thanks! |
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:/notifications/unsubscribe-auth/AOCAU4QMTWZXERLC7RMQETDSAIDMNANCNFSM4PVMPHYA>
.
|
@thundernixon |
This issue is showing up on macOS Catalina 10.15.6 with Firefox 80.0.1 as well with the Mulish font. |
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 |
@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. |
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. |
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). |
Is that the case for Firefox also? If we fix that URL, should the problem resolve? |
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. |
Set up some CodePen forks and sent to our devs. You're totally right. It works with the proper import. Thanks for helping troubleshoot. |
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. |
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. |
We need people who know about this to chime in. @Lorp @anthrotype @drott |
Maybe also https:/rsms |
@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. Variable fonts don’t need bit 6. More info: |
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:
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. 😉 |
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. |
That bar in 'A', does it have correct orientation? If it is wrong, the white is white regardless of the fill rule. |
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): The other issue about FreeType and overlaps is new and should not be confused with this one, which is about Mac OS. |
Seems OK: https://fonts.gstatic.com/s/mulish/v1/1Ptyg83HX_SGhgqO0yLcmjzUAuWexXRWwaA.ttf
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).
I see there are two TTF versions, one showing the problem: 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.) |
Apologies for the late reply, I was on holiday.
@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.
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:
|
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. |
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.
|
I had the same issue on a website project. This is gonna work. Use one of these for each font-weight: /* cyrillic-ext 300*/ |
Subscribing as I am also having this issue. |
Hi, folks (Using Chrome Version 100.0.4896.75 (Official Build) (x86_64) + MacOS Catalina 10.15.7) |
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 ) |
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). |
Oh can be usefull to know that thx ! Yes, i do with the import CSS method currently. We will wait for a right solution. |
The solution for me has been to download Montserrat font from Squirrel and then convert the files to woff and woff2. |
@Anticosti: this was a perfect workaround for me. Thank you! |
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: Try this: Hope that helps! |
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:
Before you are going to use the Font, use this CSS property in your Developer tools -webkit-text-stroke: 1.52px #75ff25; 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)
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. |
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.
The text was updated successfully, but these errors were encountered: