Exo2 not showing the right way on macOS browsers

[dennzo]

Unfortunately this font has some overlapping issues which affects a few google fonts, Exo 2.0 included.

It does not happen with all fonts weights and letters, but with some. And all the bolder font weights seem to be affected.

This issue has also been raised on the below website, but it did not make it here to GitHub. It is a known issue, which could be solved by "cleaning" the font drawing.

https://yootheme.com/support/question/138044

Is there any way this can be corrected? I would really like to use this font. :)

[m4rc1e]

I'm guessing you're using Mac OS X El Capitan?

This isn't a problem with the font per se. The issue is the renderer cannot render overlapping contours. I think we may solve this issue by serving El Capitan users fonts which do not have overlaps.

cc @garretrieger

[thlinard]

If I download the fonts through Google Webfont Helper (https://google-webfonts-helper.herokuapp.com/api/fonts/exo-2?download=zip&subsets=latin&variants=regular), I have the same issue (I'm on macOS 10.15.7, tested with the TTF, WOFF and WOFF2 files).

Edit: I don't have a full code review by far, but I suspect the user agent https://github.com/majodev/google-webfonts-helper/blob/master/server/logic/conf.js used to download the fonts might be the cause of the problem.

[dennzo]

@m4rc1e I'm guessing you're using Mac OS X El Capitan?

I am currently on macOS Catalina 10.15.6.

---

@m4rc1e This isn't a problem with the font per se. The issue is the renderer cannot render overlapping contours. I think we may solve this issue by serving El Capitan users fonts which do not have overlaps.

I can confirm, that this is not a problem with the font directly and it only occurs while rendering it on the web. It could be fixed in the font by cleaning the edges, so that nothing overlaps. But this would not be a permanent solution to the actual problem, only a fix for this one specific font.

---

@thlinard If I download the fonts through Google Webfont Helper ....

I have used the Google Webfont Helper, but I have not tried otherwise yet.

[thlinard]

I am currently on macOS Catalina 10.15.6. (…) I have used the Google Webfont Helper, but I have not tried otherwise yet.

That's what I suspected, thanks for the confirmation.

[m4rc1e]

On Catalina, I cannot replicate this issue on our main site:

How are you fetching the fonts? I do not trust the Google Webfont Helper since this not an offical Google product.

[moyogo]

If I download the fonts through Google Webfont Helper (https://google-webfonts-helper.herokuapp.com/api/fonts/exo-2?download=zip&subsets=latin&variants=regular), I have the same issue (I'm on macOS 10.15.7, tested with the TTF, WOFF and WOFF2 files).

I have used the Google Webfont Helper, but I have not tried otherwise yet.

I compared the static fonts from the official Google Fonts https://fonts.google.com/specimen/Exo+2 with the ones from majodev’s google-webfonts-helper and some flags are missing in the second set that cause this overlap issue.

Testing with https://wakamaifondue.com/ only the google-webfonts-helper fonts have the overlap issue.

You should use the official Google Fonts or have the google-webfonts-helper fonts fixed. The sample code in https://github.com/TypeNetwork/Vollkorn-Typeface/issues/8#issuecomment-655791672 can be used to fix the flags needed.

[thlinard]

How are you fetching the fonts? I do not trust the Google Webfont Helper since this not an offical Google product.

Well, the fonts do come from Google's servers (and google-webfonts-helper is referenced in https://github.com/google/fonts/blob/master/README.md). Simply, if I believe https://github.com/majodev/google-webfonts-helper/blob/master/server/logic/conf.js, the service identifies itself as Firefox 39 for a WOFF2 (and Firefox 27 for a WOFF): what are Google's servers supposed to give to a Firefox 39 when a VF is required?

google-webfonts-helper should probably update its User Agent when it requires a VF, but there are also probably some problems in fonts served to old browsers.

[m4rc1e]

what are Google's servers supposed to give to a Firefox 39 when a VF is required?

A set of instantiated static fonts which have been optimised for this browser, hence why they don't work well on Catalina.

[thlinard]

what are Google's servers supposed to give to a Firefox 39 when a VF is required?

A set of instantiated static fonts which have been optimised for this browser, hence why they don't work well on Catalina.

IMO, this is not exactly correct. We agree, on old OS and old browsers, a VF wouldn't work. But:

1. I believe that the static files served do not work well anyway, whatever the OS version (macOS anyway) and the browser: they are simply flawed. What you are going to do with fonttools/fonttools#2068 will improve this point, and it may be enough if applied to enough User Agents (google-webfonts-helper sometimes identifies itself as being on Linux, sometimes on Windows, with different browsers and versions).
2. google-webfonts-helper and other techniques like the direct use of https://fonts.gstatic.com URLs cause files intended for old systems to be served on newer browsers and OS. Regarding google-webfonts-helper (and maybe also Fontsource - google/fonts/pull/2757), there is a way to fix this if it's really a simple User Agent problem.

[m4rc1e]

1. yes, overlaps will be removed for OS X/IOS, eventually. This is still faulty. Will add that we're solving the name table issue as well

2. There's no way to stop people fetching fonts in any manner they want. We can only fix issues if people use the end points correctly.

[thlinard]

1. yes, overlaps will be removed for OS X/IOS, eventually. This is still faulty. Will add that we're solving the name table issue as well

If it's only for macOS, google-webfonts-helper really needs to change its User Agents... (but there are no more commits since November 2017!)

2. There's no way to stop people fetching fonts in any manner they want. We can only fix issues if people use the end points correctly.

As the promotion of google-webfonts-helper is done on https://github.com/google/fonts/blob/master/README.md, maybe you could add a warning.

Edit: I tested, Fontsource has the same issues on its WOFF files but not its WOFF2 files (which should make the problem quite invisible with this service).

[ayuhito]

Edit: I tested, Fontsource has the same issues on its WOFF files but not its WOFF2 files (which should make the problem quite invisible with this service).

I'm more than happy to update the relevant user agents to resolve the WOFF files too, @thlinard, though I'll need a bit more guidance on exactly what user agents can fix this (if possible).

Relevant file: fontsource/google-font-metadata.

[thlinard]

I'm more than happy to update the relevant user agents to resolve the WOFF files too, @thlinard, though I'll need a bit more guidance on exactly what user agents can fix this (if possible).

Relevant file: fontsource/google-font-metadata.

Hi @DecliningLotus

Well, the problem is with VFs, or rather the static files produced from VFs: for browsers that are too old (I suppose Chrome before version 66 or so, Firefox before version 62, Safari before version 11 or on an old macOS version), Google servers serve them static files, which are the source of the bugs exposed here, especially on macOS (Windows 10 seems more tolerant, but I don't know about Linux).

So the main goal is to avoid as much as possible to use these static files and always give the VF version to a browser that can handle it.

This is where it gets more complicated for a service like yours. I see two possibilities:

1) You're using a very recent User Agent to obtain both the WOFF and WOFF2 versions. Advantage: You get the VF version, in WOFF and WOFF2. The files don't have the bugs discussed here. Disadvantage: old browsers (but what is the market share represented?) don't know what to do with these files (or, at best, they only see the default weight). And I don't even know if there is a reliable method to get the WOFF version for sure (Raleway one weight https://fonts.googleapis.com/css2?family=Raleway&display=swap gives you the WOFF version, even on the latest browsers, but Roboto one weight https://fonts.googleapis.com/css2?family=Roboto&display=swap gives the WOFF2 version).

2) You retain an old User Agent to obtain the WOFF version (preferably a User Agent identified as macOS, since the fix will specifically target this platform) and a modern User Agent for the WOFF2 version. Advantage: the WOFF2 version will be a VF version, without the bug therefore. The WOFF version will be a static, buggy version, but at least somehow working on older browsers. Disadvantage: if the WOFF2 version is not present in the package, or incorrectly used, the static WOFF version will be used by recent browsers, with the bugs observed.

It seems that for now you're using the 2nd solution, right? As long as the VF file (the WOFF2) is served to modern browsers, the vast majority of users (Chrome before version 66, Firefox before version 62, it's starting to date…) won't see any problem.

[ayuhito]

@thlinard, thank you for the detailed description.

I believe so. It was not necessarily intentional but at least the current solution arguably works the best for now.

[apodtele]

OTF specifications explicitly ask to remove overlaps in static instances or flag overlaps.

[JulianCataldo]

Hello, I'm looking for a solution for using Exo 2 without rendering bug in macOS. I've tested Exo (1), no problem. Any work-around since then ?

Thanks a lot, and I love this font BTW