bugThe FreeType Project - Bugs: bug #59026, Multi-weight TTF of font...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  Ronan Jouchet <ronjouch>
Submitted:  Fri 28 Aug 2020 12:33:19 AM UTC
   
 
Severity:  3 - Normal Item Group:  Incorrect behaviour
Status:  Works For Me Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Planned Release:  2.10.3

Jump to the original submission

Sat 12 Dec 2020 11:01:48 AM UTC, comment #14: 


comment #13:

> For most people, TrueType is a font format as described by specifications. The 4x4 oversampling or any other kind of anti-aliasing is not described there and people try new algorithms, GPU and CPU optimizations, distance fields, etc. The anti0-aliasing quality today is much more dependent on gamma correction or contrast adjustment.
>


TD renderer already has gamma-correct four times four oversampling. The contrast adjustment is most likely an artificial render distortion (like incorrect gamma is) and depends on the renderer but in DirectWrite should be set to 0 (false) because true values distort the gamma. Classic GDI is always gamma correct. ClearType GDI has a gamma setting with no contrast. Neither oversampling nor gamma is in the scope of FreeType, however, so the FreeType implementor is encouraged to properly implement both to have anti-aliasing.

> For you and only you as far as I can tell, TrueType == GDI. That is so dogmatic and super conservative. How do you plan to build on that and make progress beyond Windows 98, which was 22 years ago?


There is no progress necessary. However, one could progress from most FreeType implementations by ignoring pixels beyond font height boundaries (unsigned Win Ascent and unsigned Win Descent), disabling the subpixel mode, implementing four times four oversampling, etc. .

>Break free, try new things, explore the unknown. It is much more satisfying than excavating GDI quirks.
>


An example is that I made a smooth filter that preserves sharp edges, yet it won't see practical use in my TrueType rendering process because while better than FreeType box filter in the smooth renderer, it is worse than four times four oversampling. I have concluded that it does not get much better than bilevel renderer and four times four oversampling. It is much more satisfying to have a fully functional and compatible free software renderer than excavating the unknown.

Anonymous
Wed 09 Dec 2020 01:56:51 PM UTC, comment #13: 

For most people, TrueType is a font format as described by specifications. The 4x4 oversampling or any other kind of anti-aliasing is not described there and people try new algorithms, GPU and CPU optimizations, distance fields, etc. The anti0-aliasing quality today is much more dependent on gamma correction or contrast adjustment.

For you and only you as far as I can tell, TrueType == GDI. That is so dogmatic and super conservative. How do you plan to build on that and make progress beyond Windows 98, which was 22 years ago? Break free, try new things, explore the unknown. It is much more satisfying than excavating GDI quirks.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 09 Dec 2020 07:29:52 AM UTC, comment #12: 


comment #11:

> If you expect bit-identity between GDI and FreeType smooth, first you need to acknowledge that 4x4 produces 16 gray levels while FreeType outputs 256 levels. So at the very least, you should only compare top 4 bits. Then I would permit one-off for occasional rounding, keeping in mind that it is hardly visible to a naked eye.
>
> I would take your arguments more seriously if you actually produced images for real (not *synthetic*) fonts or actual bit comparisons instead of your outlandish off-hand assessments.


The smooth engine does have its purpose, but it's not TrueType rendering. For TrueType rendering I use anti-aliasing unrelated to the smooth engine. It is a few lines of code to scale the outline four times and initiate the bilevel renderer and I've already implemented it in TD renderer. The four bits method is entirely incorrect because it completely misses the point that it samples specific points, that it's the bilevel renderer and dropout control and so on. Also, I refuse to use any newer version than 2.10.2, initiating a FreeType code freeze where the FreeType contributors can no longer influence the rendering quality of TD renderer.

Anonymous
Tue 08 Dec 2020 02:56:57 PM UTC, comment #11: 

If you expect bit-identity between GDI and FreeType smooth, first you need to acknowledge that 4x4 produces 16 gray levels while FreeType outputs 256 levels. So at the very least, you should only compare top 4 bits. Then I would permit one-off for occasional rounding, keeping in mind that it is hardly visible to a naked eye.

I would take your arguments more seriously if you actually produced images for real (not *synthetic*) fonts or actual bit comparisons instead of your outlandish off-hand assessments.

Alexei Podtelezhnikov <podtelez>
Group Member
Tue 08 Dec 2020 01:17:29 PM UTC, comment #10: 


comment #9:

> The 4x4 oversampling costs at least 4x more to render.
>
> The specs strongly discourage overlaps in static fonts and require that they are flagged with OVERLAP_SIMPLE and OVERLAP_COMPOUND. Variable fonts are expensive toys as is. I do not mind if they pay up in the rendering department as well. It is good to apply some evolutionary pressure on the over-designed beast. I only want some transparency about the cost of variable fonts with lazy casual overlaps.


I use four times four oversampling, and never use the smooth engine. I personally consider the smooth engine unusable for TrueType rendering because it does not match any TrueType render configuration. Four times four oversampling makes the renderer significantly much more authentic to the Microsoft renderer, and has the ability to do dropout control and makes it possible to properly stack fractional coverage pixels from different glyphs by rendering on an oversampled canvas, working exactly the same way as in the bilevel renderer. The rules for overlap rendering are well known as the non-zero winding rule (cast to bool).

Anonymous
Mon 07 Dec 2020 02:26:07 PM UTC, comment #9: 

The 4x4 oversampling costs at least 4x more to render.

The specs strongly discourage overlaps in static fonts and require that they are flagged with OVERLAP_SIMPLE and OVERLAP_COMPOUND. Variable fonts are expensive toys as is. I do not mind if they pay up in the rendering department as well. It is good to apply some evolutionary pressure on the over-designed beast. I only want some transparency about the cost of variable fonts with lazy casual overlaps.

Alexei Podtelezhnikov <podtelez>
Group Member
Mon 07 Dec 2020 11:04:34 AM UTC, comment #8: 

No, I use four times four oversampling in TD renderer and never have an issue.

Anonymous
Sun 06 Dec 2020 03:11:45 PM UTC, comment #7: 

FreeType now appreciates explicit warning flags OVERLAP_SIMPLE and OVERLAP_COMPOUND flags. Please use them.

Alexei Podtelezhnikov <podtelez>
Group Member
Sun 06 Dec 2020 09:33:09 AM UTC, comment #6: 

The smooth engine in FreeType should be avoided for many reasons including glitching like this caused by unsupported dropout control and unsupported overlaps. This would never be an issue with the bilevel renderer. Four times four oversampling should do it (as long as gasp allows anti-aliasing and v35 mode is used), and it is up to the FreeType implementor to implement it as it is out of scope for FreeType, because FreeType is mainly a font reading library, and the extra stuff like the bytecode interpreter and rasterizer are not meant to be taken seriously.

Anonymous
Sat 26 Sep 2020 06:35:03 PM UTC, comment #5: 

Please do not implement different methods depending on the glyph data. Having different glyphs render inconsistently leads to text that is uncomfortable to read.

Here are some ways to fix this:
1. handle intersects properly in the smooth engine
2. use 4×4 oversampling always if and only if grayscale gasp enabled
3. use 6×1 oversampling always if and only if symmetric smoothing gasp disabled
4. use 6×5 oversampling always if and only if symmetric smoothing gasp enabled

Speed is not everything. The application will have much higher overheads. Handling Rule 2 literally (boundary pixels turning on rather than having the larger winding) is one of the largest bottlenecks in FreeType bilevel renderer and can be removed and it would be faster than smooth engine. Nobody will care if a document of 1000 pages with over 2000 characters per page renders about 0.0001 milliseconds slower!!!

Anonymous
Fri 28 Aug 2020 03:49:39 PM UTC, comment #4: 

comment #3:

> Please read about OVERLAP_SIMPLE and OVERLAP_COMPOUND in OpenType Specifications. 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.


Thanks for the extra context.

But right now (with FreeType 2.10.2 and fonts using or not using OVERLAP_ flags), do you confirm it's reasonable to suggest Linux distro packagers to stop packaging variation fonts, and package the static fonts instead? At this point it's only a disk-space loss, right?

Ronan Jouchet <ronjouch>
Fri 28 Aug 2020 03:17:12 PM UTC, comment #3: 

Please read about OVERLAP_SIMPLE and OVERLAP_COMPOUND in OpenType Specifications. 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.

Alexei Podtelezhnikov <podtelez>
Group Member
Fri 28 Aug 2020 02:31:03 PM UTC, comment #2: 

Thanks for the fast feedback, Alexei.

[comment #1:]

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


Okay, got it: it's a performance/quality tradeoff, for most fonts it's useless so it's reasonable to err on the side of performance, and expect font developers to flag their font as needing the option rather than making all fonts suffer the performance penalty.

> I suggest that you ask CascadiaCode developers to set OVERLAP_SIMPLE or OVERLAP_COMPOUND in the variation font. Indeed, why not? Then please try current FreeType from git.


Sure, as soon as CascadiaCode provides me with a beta release with one of these flags, I'll give it a try with AUR/freetype2-git.

I'll also reach out to Arch Linux packagers of the font. I'll point them at this bug, suggest they stop packaging the variation fonts, and package the static fonts instead.

Alexei, do you confirm it's the preferable Linux distribution packaging path:
 1. Right now with FreeType 2.10.2?
 2. If it is right now, should it be the preferable path forever, even if/when A. CascadiaCode releases a version with an OVERLAP_ option and B. FreeType in Arch is updated to the upcoming release with support for these flags?

Ronan Jouchet <ronjouch>
Fri 28 Aug 2020 01:14:43 PM UTC, comment #1: 

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.

So I suggest that you ask CascadiaCode developers to set OVERLAP_SIMPLE or OVERLAP_COMPOUND in the variation font. Indeed, why not? Then please try current FreeType from git.

Alexei Podtelezhnikov <podtelez>
Group Member
Fri 28 Aug 2020 12:33:19 AM UTC, original submission:  

This is a followup of Cascadia Code bug "[linux + VariableTTF-specific]
Some glyphs (e.g. a '4', or the bottom-right stem of lowercase 'u') look
weird at certain sizes, maybe due to mis-handling overlapping paths of
variable font", [FONTBUG]

Font "Cascadia Code" (zip artifact available at [FONTZIP]) ships:
 1. `ttf/CascadiaCode.ttf`, a multi-weight TTF bundle
 2. `ttf/static/CascadiaCode-{Regular,Bold,...}.ttf`, individual TTF fonts
 3. `otf/static/CascadiaCode-{Regular,Bold,...}.otf`, individual OTF fonts

Fonts 2. and 3. (individual OTF/TTF fonts) do display fine on my machine,
but the font bundle 1. (packaging all the weights in a single .ttf file)
render with artifacts. A particularly noticeable one is a protrusion on the
inner-right side of the bottom curve of a `u`, but it isn't the only one.

Screenshots:

 1. ftview of the multi-font bundle showing glitches:
   `ftview -d 1024x768x24 30 CascadiaCode-2008.25/ttf/CascadiaCode.ttf`

 2. ftview of the `-Regular` single font showing no glitches:
   `ftview -d 1024x768x24 30 CascadiaCode-2008.25/ttf/static/CascadiaCode-Regular.ttf`

 3. A looping GIF animating between 1. and 2.

 4. A close-up on a few problematic letters.

Discussing with one of the font maintainers at [FONTBUG], they say they cannot
reproduce the problem under Windows/macOS, and suspect a FreeType bug, saying:

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


, or maybe something is wrong in their font build, and only noticeable in FT?

Bug confirmed on:
 - FreeType 2.10.1-2 (from the official Ubuntu 20.04.1 package, [PKG/UBUNTU])
 - FreeType 2.10.2-1 stable (from the official Arch package, [PKG/ARCH])
 - FreeType 2.10.2+p53+g6730854c3 (from AUR package freetype2-git, [PKG/AUR])

Any idea of what's wrong?

Thanks for FreeType and sorry if this is a dupe; I did my best to search
for existing bugs but am not familiar with font terminology.

[FONTBUG] https://github.com/microsoft/cascadia-code/issues/350
[FONTZIP] https://github.com/microsoft/cascadia-code/releases/download/v2008.25/CascadiaCode-2008.25.zip
[PKG/UBUNTU] https://packages.ubuntu.com/focal/freetype2-demos
[PKG/ARCH] https://www.archlinux.org/packages/extra/x86_64/freetype2/
[PKG/AUR] https://aur.archlinux.org/packages/freetype2-git/

Ronan Jouchet <ronjouch>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by ronjouch (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-06 podtelez StatusConfirmed Works For Me
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.10.3
    2020-08-28 podtelez StatusNone Confirmed
    2020-08-28 ronjouch Attached File- Added cascadiacode-1-bad-multiTtfBundle.png, #49715
        Attached File- Added cascadiacode-2-ok-singleTtfRegular.png, #49716
        Attached File- Added cascadiacode-3-animation.gif, #49717
        Attached File- Added cascadiacode-4-glitches-detail.png, #49718

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code