Glyphs with internal overlaps render incorrectly

[Vozka]

OS: Windows 10 21H2 19044.1766

Application: All latest Affinity suite applications afaik. I first noticed it in Publisher, so I'm putting it here.

 

Problem: Some fonts contain glyphs made of several components that overlap. Affinity applications seem to not handle this correctly, which sometimes creates subpixel errors (see image below). The font I'm using as an example is Comfortaa, but unfortunately this seems to happen in (static versions of) various Google fonts.

I first thought this was a bug in Google fonts, but they assured me that this is deliberate, it's how they will continue to generate their static fonts and any applications are supposed to render it correctly. I don't know if their decision is reasonable, but it means that this is not going away.

 

Current workaround: Individual font repositories in the Google fonts github seem to contain static versions of the fonts different than the Google fonts website, and at least with Comfortaa it does not have this issue. 

However it took me several hours of work spread over several days (due to communication with the font author and a Google github person) to diagnose the issue and find this workaround and I don't think it's reasonable to expect users to do this.

 

Here's an image from Publisher showing a problem with "h". With various font sizes and weights it happens with other glyphs as well, although usually not as obviously:

 

Here's a screenshot from a completely different application, Blender, in which this font is even more broken. I'm adding it because it shows the components that the glyph is made from (I don't have a specialized application for that) - the rendering issue in Publisher clearly happens in a place where several components overlap. Blender has trouble identifying which side of a component boundary is inside and which is outside (that is why parts of the glyphs are hollow). I wonder if that has something to do with the rendering issues in Affinity suite. 

[stokerg]

Hi @Vozka,

Could you please attach your afpub file that you've shown in the screenshots?  I can replicate this but not to the same degree that you show in your screenshots, in my results its very hard to even notice there is an issue, where as in your screenshot there clearly is and issue.  

[Vozka]

Sure! 

This is the project file. It uses Comfortaa regular and semi-bold. 

EDIT: I'm sure you did that, but just in case, it's important to use the static fonts downloaded from here by clicking on the "download family" button.

comfortaa publisher.afpub

 

The magnitude of the error depends on the zoom, or dpi of the rasterized file when exporting. 

Just to be sure, I'm adding another screenshot of how the document looks with 100% zoom on my machine, because I cannot say for sure that the screenshot in my previous post was taken with 100% zoom:

 

Also here's a screenshot from Photo, where it's easier to produce the issue since the Text tool is immediately rasterized. The fonts are Comfortaa regular (top left), medium (bottom left) and bold (right), size is 9 pts. There are smaller issues visible on the other glyphs too in certain weights.

comfortaa publisher.afpub

[joe_l]

I see some faults while changing the zoom, but there are no faults in the exported PDF. Maybe just a screen rendering problem?

[Vozka]

6 minutes ago, joe_l said:

I see some faults while changing the zoom, but there are no faults in the exported PDF. Maybe just a screen rendering problem?

When exporting to pdf the rendering issue gets delegated to the pdf rendering application. I don't use Adobe Reader, but I assume they would not have this issue. When exporting to say .png it is slightly less visible than in application (and dependent on DPI), but still present.

 

 

 

Another thing, don't know if it helps:

Rendering issues with this font seem to be really common, so I tested various applications to find any differences.

I found two applications that seem to handle it with zero issues: Firefox (or at least its pdf viewer) and the development (2.99.x) version of Gimp. From joe_l's message above I suspect Adobe suite might also handle it fine. 

Chromium or SumatraPDF also render it incorrectly, but less so than Affinity suite. The issue is about 50% less visible and only manifests on "h".

In Affinity suite, especially Photo, and also in the stable 2.10.x version of Gimp for example the issue is clearly visible, and with different weights also manifests on other glyphs.

[MikeW]

On 6/25/2022 at 1:28 PM, Vozka said:

...Current workaround: Individual font repositories in the Google fonts github seem to contain static versions of the fonts different than the Google fonts website, and at least with Comfortaa it does not have this issue. ...

The main difference in the github and GF font versions is that the GF versions are made of the component, overlapping parts derived directly from the Variable version as can be seen here:

While the github version has its static version made with overlaps removed:

 

[Old Bruce]

I am a little bit confused. Is this about a poorly made font having artifacts appear?

[Vozka]

3 minutes ago, Old Bruce said:

I am a little bit confused. Is this about a poorly made font having artifacts appear?

This is about a professionally made font that Google claims is made entirely correctly, and viewing the glyphs in an editor also doesn't immediately show issues (except being made from several components, but the components seem to be perfectly aligned). But several (not all!) applications do show issues when rendering it, Affinity suite being one of the worse ones.

Since this is a feature of the Google Fonts system, it is probable that this is not the only font affected, but I don't have the time to go through all of them.

 

10 minutes ago, MikeW said:

The main difference in the github and GF font versions is that the GF versions are made of the component, overlapping parts derived directly from the Variable version as can be seen here:

[...]

Yes, I was just downloading FontForge and looking at the glyph as well to check that the components are not misaligned, but they don't seem to be. What I found funny was that the preview rendering system in FontForge also has the rendering issue, just as bad as Photo or stable version of Gimp.

[Old Bruce]

6 minutes ago, Vozka said:

This is about a professionally made font that Google claims is made entirely correctly, ... But several (not all!) applications do show issues when rendering it....

Who are you going to trust; Google or your own eyes? Toss the font out.

[Vozka]

5 minutes ago, Old Bruce said:

Who are you going to trust; Google or your own eyes? Toss the font out.

My eyes tell me that the rendering is broken and (in a glyph outline editor) they also tell me that the glyph itself does indeed seem to be correct (and that other applications do render it correctly).

I am unable to toss it out for the current project for various reasons.

 

The main issue is that this seems to be a feature of one of the biggest providers of free fonts. Therefore there are going to be more people experiencing this problem with other fonts too and potentially spending hours needlessly, trying to investigate it and find a workaround. If there was some information saying "we don't support fonts made of multiple components, please download single-component static font at xxxxx", I'd be okay with that. But there isn't and it takes a layman a ton of time to get it.

[MikeW]

44 minutes ago, Old Bruce said:

I am a little bit confused. Is this about a poorly made font having artifacts appear?

No, the font is technically correct. 

Various rendering engines, especially those that do not support variable fonts, can render each component with artifacts, including the artifacts shown in this thread. 

Many Google fonts on the GF website do have various issues in many applications. 

[Old Bruce]

45 minutes ago, Vozka said:

I am unable to toss it out for the current project for various reasons.

 

24 minutes ago, MikeW said:

Many Google fonts on the GF website do have various issues in many applications.

Then stay away from that website. This isn't rocket surgery. Use the proper rendering font from the Github repository.

[MikeW]

6 minutes ago, Old Bruce said:

Then stay away from that website. This isn't rocket surgery. Use the proper rendering font from the Github repository.

I just fix them.

There are issues at the github repository for some fonts too. Often, the same GF fonts via Font Squirrel do not have the same issues (except the feature coding errors).

There are also issues with some Adobe fonts. And with many commercial fonts direct from their respective foundry websites and/or the resellers (like MyFonts but not limited to MF). I've had unexpected issues with fonts I've either wholly made or feature coded. Crap happens.

This rendering issue may be up to the OS renderer or the applications or a combination of the two. Serif can only fix an issue with their applications should it exist.

[Vozka]

45 minutes ago, Old Bruce said:

 

Then stay away from that website. This isn't rocket surgery. Use the proper rendering font from the Github repository.

Once again, the reason why I'd like to have this fixed is because

a) it is not reasonable to expect a common user to know this

b) it took me hours of my life to diagnose the issue and find out how to fix it and I think others should not be forced to do the same. 

Perhaps you notice in my original post that I do actually know to use the github fonts instead because I stated that this is a workaround. This post is about preventing other people from having to also spend significant amount of time (and potentially failing) because of an issue that is not going away (Google fonts are popular) and at this moment seems to be on Serif's side. 

 

Your advice does not help me in any way and muddies the thread. Please do not waste your time any more unless you have ideas about the technical side of the problem. 

[kenmcd]

Another workaround is to use the OTF fonts if available.
OpenType-PS (.otf) fonts do not use components so they will not have overlaps (for now).

To support variable fonts, text rendering engines must support properly rendering overlaps.
So apps which support variable fonts have already dealt with this issue.

Typically when font developers export their fonts from their GlyphsApp, or FontLab source files, they select "Remove Overlaps" as one of the export parameters.
So the fonts they provide in their repo generally do not have overlaps in the TTF files.

Google Fonts takes the original source files and uses their own tools to build the fonts for GF.
That does not include "remove overlaps" (fonttools can do it but it is not 100%).
Overlaps is not the only rendering issue they have to contend with.
There are a number of other issues where the rendering in apps does not work properly.
And that includes Adopey, Apple, and others. Bugs. All the time.
They have made the decision to not modify valid fonts to work around various app limitations.
Otherwise you end up with a bunch of non-standard franken-fonts.

So until Affinity supports variable fonts, the easiest workaround is to use the OTF fonts.
If it does not need to remain text, you can merge the shapes too.