Here's another slightly bigger size looking funky:

Hi. What is interesting is that you can see on the 4 that it appears that the diagonal stroke is extending past the horizontal one. I'm guessing that you've installed the variable font version (since what you're observing happens where different strokes overlap). Did you install the OTF or TTF version?

However, I am not able to repro the issue that you're observing on Windows or Mac, which makes me suspect that it has something to do with how ubuntu is interpreting the font.

@aaronbell thanks for the fast feedback.

What is interesting is that you can see on the 4 that it appears that the diagonal stroke is extending past the horizontal one.

Indeed 👍.

I'm guessing that you've installed the variable font version (since what you're observing happens where different strokes overlap).

What do you mean by "the variable font version"?

Did you install the OTF or TTF version?

I had installed the TTF version. And, lo and behold, the OTF version doesn't exhibit the issue! Here's a screenshot of the OTF version at the same size as the initial screenshot (14.7), the problem is gone (but now descenders for y g j are cut, gah 😄, maybe this is my terminal's problem, though)

However, I am not able to repro the issue that you're observing on Windows or Mac, which makes me suspect that it has something to do with how ubuntu is interpreting the font.

Not just Ubuntu, though, I see the same thing on my Arch Linux machine (and I will confirm it's gone switching to OTF). So, maybe a bug in a common rendering library? Which one is responsible for this exactly? FreeType? Harfbuzz?

In the 2008.25 package, there are static OTFs (each weight is a separate .otf) and TTFs, both variable (all styles are contained within one .ttf file) and static (each weight is a separate .ttf).

When you installed the TTF version, did you install CascadiaCode.ttf or CascadiaCode-Regular.ttf?

In the 2008.25 package, there are static OTFs (each weight is a separate .otf) and TTFs, both variable (all styles are contained within one .ttf file) and static (each weight is a separate .ttf).

When you installed the TTF version, did you install CascadiaCode.ttf or CascadiaCode-Regular.ttf?

@aaronbell my initial report was with the variable TTF (all styles in one .ttf). After a rm -rf ~/.local/share/fonts/Saja* && fc-cache -fv followed by an install of static Cascadia_Code_Regular.ttf + Cascadia_Code_Bold.ttf, things look good (as good as when I installed OTF Regular+Bold, in my previous post):

→ Yes, the problem is specific to the variable TTF (all styles are contained within one .ttf file).

What could explain this?

It is probably an issue with FreeType's method of dealing with variable fonts, or fonts that have overlapping paths within one glyph (normally these overlaps are removed, but for variable fonts it is useful to preserve them).

Which version of FreeType are you running? According to the FreeType page you should be running 2.9 at minimum for proper Variable font support.

Which version of FreeType are you running? According to the FreeType page you should be running 2.9 at minimum for proper Variable font support.

@aaronbell I'm running the libfreetype6 2.10.1 package shipping as part of Ubuntu 20.04. Do you suggest I report this as a potential FreeType bug?

From what I can tell, that package doesn't look like it has the most up-to-date version of FreeType. Can you try upgrading to the latest? If the latest still shows the issue, then yeah, it should be reported.

From what I can tell, that package doesn't look like it has the most up-to-date version of FreeType. Can you try upgrading to the latest? If the latest still shows the issue, then yeah, it should be reported.

@aaronbell no and yes. No because in a non-rolling-release Linux (like Ubuntu), you never upgrade such a core package out of major versions, that's a recipe for a broken system. That being said, yes because my home machine runs Arch (which is a rolling release currently shipping the latest freetype 2.10.2) and exhibits the problem. Will file a bug upstream and closing this one. Thanks for all the guidance.

@aaronbell FYI, as I'm preparing the FreeType bug report:

• (Broken multi-font bundle) ftview -d 1024x768x24 30 CascadiaCode-2008.25/ttf/CascadiaCode.ttf
  
• (Good single font) ftview -d 1024x768x24 30 CascadiaCode-2008.25/ttf/static/CascadiaCode-Regular.ttf:
  
• A looping GIF animating between both:
  

Filed FreeType bug #59026: Multi-weight TTF of font "Cascadia Code" renders artifacts on some glyphs

Thank you!

FreeType will handle overlapping contours in the next release but it will require OVELAP_SIMPLE or OVERLAP_COMPOUND set. We understand that those flags are optional in variation fonts but oversampling quadruples the rendering time. Buyer beware.

FreeType will handle overlapping contours in the next release but it will require OVELAP_SIMPLE or OVERLAP_COMPOUND set. We understand that those flags are optional in variation fonts but oversampling quadruples the rendering time. Buyer beware.

Thanks @apodtele . @aaronbell, Alexei also posted a few more details on the FreeType bug that should be of interest to you. Quoting them here:

You correctly identified the issue: overlapping contours can produce pixels with inflated coverage because FreeType normally integrates the coverage. To mitigate the artefacts, oversampling is necessary (increase resolution 4x4 and average the results).

We implemented this recently but it quadruples the rendering time. Only glyphs with explicit OVERLAP_SIMPLE or OVERLAP_COMPOUND would be subject to oversampling.

Those flags are required in static fonts with overlaps. CascadiaCode just removes the overlaps in the static fonts, which is even better alternative. The flags are optional in variation fonts however but not all variation fonts have overlaps. We stopped short of enabling oversampling for all variation fonts.

Alexei also comments about OVERLAP_SIMPLE and OVERLAP_COMPOUND in the OpenType
specs:

On one hand in variable fonts, "use of this flag is not required in OpenType". On the other hand in static fonts, "either set this flag in the derived glyph data, or else should merge contours to remove overlap". Hopefully, the next version of the specs will recommend these flags in variation fonts just to be consistent.

It will be hard to change the current practice before the specs mature. So it is a long road ahead with some discussions to be had.

@aaronbell, can you build me a pre-release version of CascadiaCode with one of the OVERLAP_ flags set? I'll test it with the latest git version of FreeType.

Side note: over at the FreeType bug I'm also asking what's the path forward for distribution packagers.

Thanks for the investigation and info on this. It appears that the python library that we're using to build the Variable font doesn't automatically implement the OVERLAP_SIMPLE or OVERLAP_COMPOUND flag where it should be. AFAIK, this isn't a problem in the Mac / Windows rasterizers, but seems that it is in FreeType. I'll investigate further.

@ronjouch Can you test the attached font?
[removed]

(BTW, this font does not contain hinting, which may cause other unexpected changes, but I wanted to see if my fix actually resolved the overlap issue)

Can you test the attached font? [removed]

(BTW, this font does not contain hinting, which may cause other unexpected changes, but I wanted to see if my fix actually resolved the overlap issue)

@aaronbell (cc @apodtele) problem fixed if using that font and FreeType 2.10.2+p53+g6730854c3 (but not FreeType 2.10.2 stable). For completeness, what flag/changes did you use to produce this build?

Proof: screenshots of ftview -d 1024x768x24 30 CascadiaCodeTEST.ttf,

1. With FreeType 2.10.2 stable: broken, with artifacts:
   
2. With FreeType 2.10.2+p53+g6730854c3: fixed, no artifacts:
   
3. A GIF animating between both:
   

I think that the root of the problem is in the rasterizer implementation

• Microsoft rasterizer is based on 4x4 oversampling for anti-aliasing which is likely slower but handles overlaps naturally. Microsoft even omitted these flags in the earlier versions of specification.
• Apple rasterizer is probably based on integration, which is likely faster but does not handle overlaps well. Hence they care about the OVERLAP_SIMPLE or OVERLAP_COMPOUND flags but probably give in and do oversampling on top of integration for all variable fonts. This is just a guess and they might have a fast algorithm to detect overlaps.
• FreeType is certainly based on integration. We would like to be explicit about oversampling by setting the flags because it quadruples the rendering time. We did not investigate if detecting overlaps is plausible.

Thus this is an active area...

Thank you for your help! For this test version of the font I adapted @chrissimpkins's code from here to the build process. This forces the OVERLAP_SIMPLE or OVERLAP_COMPOUND flags to be applied to all glyphs if simple or compound, respectively.

Perhaps a bit of a brute force approach, but it solves the problem.

@apodtele My understanding aligns with yours—for variable fonts, MacOS acts as if the OVERLAP_SIMPLE and OVERLAP_COMPOUND flags are present, even if not actually set in font.

Seems that FreeType is the only rasterizer that actually cares if the flags are present in a variable font.

Ideally, only glyphs with overlaps should have these flags set. I wonder what @madig is doing.

Would you like to bring this up on freetype-devel? I honestly have no idea how prevalent the overlaps in variable fonts. I would like to see overlap-free variable fonts if it is practical.

If this is any indication he's putting it everywhere 😆 .

Overlaps are actually extremely common in variable font development. For example, at extreme heavy weights, glyphs often have greater amount of overlap than they do at the extreme light end. If overlaps were removed in such a situation, it would be impossible to preserve master compatibility. So preserving outline overlaps is a necessity.

From what I have found, it sounds like this issue has already been raised several times on the FreeType mailing list, so I wouldn't be adding anything more to the discussion 😄.

Seems that FreeType is the only rasterizer that actually cares if the flags are present in a variable font.

macOS < 10.16 cares, too.

I honestly have no idea how prevalent the overlaps in variable fonts. I would like to see overlap-free variable fonts if it is practical.

The usual (most common) open-source pipeline to make VFs is based on ufo2ft, which currently doesn't do anything, so there are unlikely to be many VFs with those flags set...

If you agree with setting the flags explicitly, we are on the same page and the specs will catch up eventually by recommending these flags. Implying the overlaps in all variable fonts seems to be an overkill unless I miss something. That is what needs to be discussed in a larger community.

If you agree with setting the flags explicitly

Sure, even if this is to work around an InDesign bug.

That is what needs to be discussed in a larger community.

Use this community: googlefonts/ufo2ft#402, it's the only one I care about ☺

On the distro packaging side, I filed Arch FS#67746 - [ttf-cascadia-code] Some glyphs show artifacts due lack of overlap support in FreeType 2.10.2, where I suggest they switch to packaging the static fonts (with the caveat of increased disk space) until the font is patched with OVERLAY flags and a stable FreeType release supports them.