search

microsoft / cascadia-code

This is a fun, new monospaced font that includes programming ligatures and is designed to enhance the modern look and feel of the Windows Terminal.
Other
25.8k stars 802 forks source link

[Linux/FreeType + VariableTTF-specific] Some glyphs (e.g. a '4', or the bottom-right stem of lowercase 'u') look weird at certain sizes, due to mis-handling overlapping paths of variable font. Needs FreeType 2.10.3 and font flag OVERLAP_{SIMPLE, COMPOUND} #350

Closed ronjouch closed 4 years ago

ronjouch commented 4 years ago

Environment

Cascadia Code version number: 2008.25
Application used to display text: VS Code 1.48.2, Firefox 80.0, Kitty 0.18.3, everywhere
OS platform and version: Ubuntu 20.04.1
Screen resolution (i.e. 220dpi): I don't know

Steps to reproduce

Display a u at size 14.7

Expected behavior

u is good-looking

Actual behavior

u looks weird: the bottom right stem has sort of a glitch, where it overlaps to the inside part of the curve:

screenshot_cascadia-code-weird-u_2020-08-27-10:37:25

ronjouch commented 4 years ago

Here's another slightly bigger size looking funky:

screenshot_other-size_2020-08-27-10:40:59

aaronbell commented 4 years ago

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.

ronjouch commented 4 years ago

@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)

screenshot_otf_2020-08-27-12:40:51

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?

aaronbell commented 4 years ago

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?

ronjouch commented 4 years ago

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):

screenshot_ttf-static_2020-08-27-13:04:43

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

What could explain this?

aaronbell commented 4 years ago

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.

ronjouch commented 4 years ago

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?

aaronbell commented 4 years ago

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.

ronjouch commented 4 years ago

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.

ronjouch commented 4 years ago

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

ronjouch commented 4 years ago

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

aaronbell commented 4 years ago

Thank you!

apodtele commented 4 years ago

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.

ronjouch commented 4 years ago

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.

aaronbell commented 4 years ago

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.

aaronbell commented 4 years ago

@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)

ronjouch commented 4 years ago

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: screenshot_cascadiacodeTEST-freetype2102stable_2020-08-28-12:31:34
  2. With FreeType 2.10.2+p53+g6730854c3: fixed, no artifacts: screenshot_cascadiacodeTEST-freetype2102+p53+g6730854c3_2020-08-28-12:32:37
  3. A GIF animating between both: screenshot_cascadiacodeTEST-animation
apodtele commented 4 years ago

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

Thus this is an active area...

aaronbell commented 4 years ago

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.

aaronbell commented 4 years ago

@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.

apodtele commented 4 years ago

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.

aaronbell commented 4 years ago

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 😄.

madig commented 4 years ago

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...

apodtele commented 4 years ago

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.

madig commented 4 years ago

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: https://github.com/googlefonts/ufo2ft/issues/402, it's the only one I care about ☺

ronjouch commented 4 years ago

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.