[Bug 1645763] New: ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Bug ID: 1645763
           Summary: ClearType enablement: strong color fringing that is
                    not present in vanilla build from freetype git
           Product: Fedora
           Version: 29
         Component: freetype
          Assignee: [e-mail]
          Reporter: [e-mail]
        QA Contact: [e-mail]
                CC: [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail], [e-mail],
                    [e-mail]

Created attachment 1500899
  --> https://bugzilla.redhat.com/attachment.cgi?id=1500899&action=edit
Scrrenshot of package and git FreeType font rendering

Description of problem:
I usually compile from source to stay up to date. Tried the new
ClearType-enabled package and got strong color fringing that I don't see in
vanilla source builds.

Version-Release number of selected component (if applicable):
2.9.1-6

How reproducible:
1. Turn on subpixel rendering in GNOME Tweak Tools, restart GNOME shell and
look at fonts.
2. Compile freetype from upstream source and LD_PRELOAD it for Firefox, etc.

Actual results: See screenshot.zip -> package.png

Expected results: See screenshot.zip -> git.png

Also:
I don't think you need freetype-2.9-ftsmooth.patch. I don't even think you need
to define the SUBPIXEL_RENDERING option at all, since FT comes with a different
and maybe not patent encumbered subpixel rendering method by default and I
couldn't tell the difference in quickly switching screenshots.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #1 from Kevin Kofler  ---
As I understand it, there is no subpixel filtering in FreeType without
SUBPIXEL_RENDERING. Whatever subpixel rendering, if any, you get without it
depends on the toolkit. Most will just render in grayscale anti-aliasing. Qt
has some dumb fallback subpixel filter that may or may not be patented. (It
should not matter anymore at this point, with the patent being covered by the
OIN.) GTK+ might these days be doing something similar to what Qt does, I don't
know. Last I checked, it was all grayscale, but that was a while ago.

Subpixel rendering is always a tradeoff between sharpness and color neutrality.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #2 from Kevin Kofler  ---
So, looking at it, the alternate algorithm:
> Note that this feature is covered by several Microsoft patents and
> should not be activated in any default build of the library.  When this
> macro is not defined, FreeType offers alternative LCD rendering
> technology that produces excellent output without LCD filtering.

(from the documentation of FT_CONFIG_OPTION_SUBPIXEL_RENDERING)
was introduced in FreeType 2.9, and the ftsmooth patch appears to go out of its
way to disable it. It looks like it is not clear what exactly is actually
covered by patents.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #3 from Nikolaus Waxweiler  ---
The alternative (or: default) subpixel rendering implementation has not been
checked for patent violations as far as I know (as in, we contacted someone
from Red Hat who would forward it to one of their lawyers, but there has been
no follow-up mail), but I suppose that is now moot.

The thing here is that something is going on with the LCD filter. If I use the
package-provided libfreetype.so, the color fringing is stronger than if I use a
compiled-from-source vanilla libfreetype.so without any changes to compile
options or system settings. Both defining FT_CONFIG_OPTION_SUBPIXEL_RENDERING
and leaving it undefined produces the same result.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Christian Stadelmann  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #4 from Christian Stadelmann  ---
This is a regression in freetype-2.9.1-6.fc29, I think. freetype-2.9.1-4.fc29
with freetype-freeworld from rpmfusion is fine.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #5 from Nikolaus Waxweiler  ---
I think I narrowed it down: simply defining FT_CONFIG_OPTION_SUBPIXEL_RENDERING
without changing anything else (i.e. recompiling other packages) gives you
subpixel rendering, but e.g. Gtk3 will not filter it. Leaving FreeType vanilla
(thereby using the alternative subpixel rendering method that, according to the
comment above the FT_CONFIG_OPTION_SUBPIXEL_RENDERING define, does not need
filtering) gives you proper looking subpixel rendering.

So I guess there's two possibilities:
1) Try to recompile cairo/Qt for these changes.
2) Delete freetype-2.3.0-enable-spr.patch and freetype-2.9-ftsmooth.patch and
use the alternative implementation that works surprisingly well, at least on my
landscape-rotated, RGB-subpixel monitor.

The alternative implementation does not support setting LCD filters manually
(as it is essentially the light LCD filter), so one would not be able to use
fontconfig's lcdfilter settings. I think. Not sure if this affects anything
else.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

David H. Gutteridge  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #6 from David H. Gutteridge  ---
(Adding myself to CC list for visibility, this is significant for me, too.)

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #7 from Kevin Kofler  ---
(In reply to Nikolaus Waxweiler from comment #5)
> I think I narrowed it down: simply defining
> FT_CONFIG_OPTION_SUBPIXEL_RENDERING without changing anything else (i.e.
> recompiling other packages) gives you subpixel rendering, but e.g. Gtk3 will
> not filter it.

But then why:

(In reply to Christian Stadelmann from comment #4)
> freetype-2.9.1-4.fc29 with freetype-freeworld from rpmfusion is fine.

? It should be affected by the same issue!

Qt should not need to be recompiled, it specifically supports subpixel
rendering at runtime (since 5.6):
http://code.qt.io/cgit/qt/qtbase.git/commit/src/gui/text/qfontengine_ft.cpp?...

Qt 4 is patched in Fedora with the same change:
https://src.fedoraproject.org/cgit/rpms/qt.git/tree/qt-x11-opensource-src-4....
(I added that to make freetype-freeworld work right, long before Qt upstream
finally fixed it.)

But if GTK+ is similarly broken, it should get fixed!

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #8 from Nikolaus Waxweiler  ---
A quick LD_PRELOAD test with
https://download1.rpmfusion.org/free/fedora/releases/29/Everything/x86_64/os...
shows that the package does actually have the same problem in Gtk3 (e.g.
gnome-calculator) and works fine with in Qt5 (e.g. featherpad).

So, Gtk3 and/or cairo got something in need of patching I think?

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #9 from Nikolaus Waxweiler  ---
Created attachment 1502223
  --> https://bugzilla.redhat.com/attachment.cgi?id=1502223&action=edit
Qt5 screenshot of subpixel rendering with freetype-freeworld

Example screenshot of a Qt5 application (featherpad settings dialog). This is
how subpixel rendering should look like (not exactly, but good enough for now).

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #10 from Nikolaus Waxweiler  ---
Created attachment 1502224
  --> https://bugzilla.redhat.com/attachment.cgi?id=1502224&action=edit
Example screenshot of Gtk3 application

This is how it should not look like (in Gtk3). Note the color fringes on the 4
and various lowercase letters.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #11 from Kevin Kofler  ---
So this looks like a Gtk3/Cairo bug, should we reassign it?

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #12 from Nikolaus Waxweiler  ---
Dunno, maybe let's an see what happens 😁

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #13 from Marek Kašík  ---
Hi, I'm looking at this issue (I've returned back to the office today). But I
don't have a conclusion yet.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #14 from Nikolaus Waxweiler  ---
On the danger of stating the obvious, have you tried recompiling cairo/Gtk3
while pointing them at the new package? Not sure if Firefox might need some
recompile also or if it uses a shared Skia or cairo or something?

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Alexei Podtelezhnikov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #15 from Alexei Podtelezhnikov  ---
FWIW, most but not all ClearType patents (with priority date 1998-10-07) appear
to have expired.

Please check with your attorneys and stop gutting FreeType perhaps.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #16 from Alexei Podtelezhnikov  ---
Ahhh.. Behdad Esfahbod pointed to this

https://azure.microsoft.com/en-us/blog/microsoft-joins-open-invention-networ...

So Fedora can simply chose between ClearType and Harmony perhaps even
retrospectively for Fedora 28 and 29.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Dawid Zych  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #17 from Dawid Zych  ---
Created attachment 1503296
  --> https://bugzilla.redhat.com/attachment.cgi?id=1503296&action=edit
white text on black background

This is rather extreme example. There's color fringing when using
freetype-freeworld too, but not *that* much.

URL: https://www.phoronix.com/scan.php?page=article&item=amazon-ec2-m5a&n...

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #18 from Marek Kašík  ---
The visible color fringing is caused by cairo using FT_LCD_FILTER_LEGACY as a
default lcd filter. It was chosen when the code was introduced to cairo (see
https://bugs.freedesktop.org/show_bug.cgi?id=10301 and
https://gitlab.freedesktop.org/cairo/cairo/commit/7a023a62f7517ad0d54f4d59c9...
for more details).

You can reproduce this by running:

pango-view --backend=cairo --dpi=134 --font="Cantarell Regular 11"
--text="4444"

or by running:

ftview -r 134 -m "4444" 11 /usr/share/fonts/cantarell/Cantarell-Regular.otf

and pressing "D" and then "L" until you get legacy filter (the gnome-calculator
uses 1.4x font scale and it was probably on 96dpi screen => ~134dpi).

Question is what to do with it. Possibilities are:

1) Ask cairo maintainers to change the default lcd filter (to which one? I
would prefer FT_LCD_FILTER_LIGHT but there is FT_LCD_FILTER_DEFAULT in freetype
so it should be it probably)
2) Add a configurable option to Gnome and let users configure it as subpixel
rendering itself
3) Select a filter in freetype code by default (Which one? And others might
prefer to configure it still.)
4) Use Harmony (it does not use LCD filters)

I would go with number 1 for now.

Btw, you can change the lcd filter by setting e.g. "Xft.lcdfilter: lcdlight" in
"~/.Xresources" for now (see
https://wiki.archlinux.org/index.php/font_configuration for additional info).

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #19 from Alexei Podtelezhnikov  ---
Please do not re-start the debate about filters. This has been thoroughly
studied and published:
https://pdfs.semanticscholar.org/15e7/43f090862d29ca3159f79aee85b49b029a04.p...

In summary, use either DEFAULT or LIGHT. They are both within the paper
conclusions. DEFAULT is wider and blurrier and therefore more resistant to
incorrect gamma correction. LIGHT is as good as it gets provided that gamma
correction is also used.

Harmony is bit-identical to LIGHT withing small rounding error. In the next
release it will be possible to tune Harmony for some PenTile displays, which is
impossible with simple filters. That might be a reason to prefer Harmony.

We at FreeType might soon consider enabling filtering by default so that users
are not forced to make a choice, rather NONE will need to be selected.

Finally it is possible to undefine USE_LEGACY in ftlcdfil.c, so that it is
never used.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #20 from Nikolaus Waxweiler  ---
Created attachment 1503858
  --> https://bugzilla.redhat.com/attachment.cgi?id=1503858&action=edit
Qt5 OTF font rendering

Aaaaah! Yes, I remember now that you need to explicitly set the LCD filter for
cairo. This bit me years ago, a simple `sudo ln -s
/usr/share/fontconfig/conf.avail/11-lcdfilter-light.conf /etc/fonts/conf.d/`
fixes it.

I think both changing cairo to use DEFAULT by default and linking the
fontconfig config file should fix this.

A GNOME interface would probably be nice, although I'd like Gtk/cairo to
implement linear alpha blending and gamma correction first.

Unrelated but I had to share the attachment. It shows correct font rendering in
the text view by Qt5 using the default Harmony rendering method.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #21 from Nikolaus Waxweiler  ---
https://gitlab.freedesktop.org/cairo/cairo/merge_requests/1

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

David  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                   |                            |m

--- Comment #22 from David  ---
Could someone quickly confirm with:

echo "Xft.lcdfilter: lcdlight" >>"$HOME/.Xresources"

and:

freetype-2.9.1-6.fc29

On a vanilla install of Fedora 29 font rendering will be correct, as it was
with the freeworld package on Fedora 28? Thanks.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #23 from Marek Kašík  ---
(In reply to Nikolaus Waxweiler from comment #21)
> https://gitlab.freedesktop.org/cairo/cairo/merge_requests/1

Thank you for the merge request.

(In reply to Alexei Podtelezhnikov from comment #19)
> We at FreeType might soon consider enabling filtering by default so that
> users are not forced to make a choice, rather NONE will need to be selected.

This would simplify my decision.
> We at FreeType might soon consider enabling filtering by default so that users
> are not forced to make a choice, rather NONE will need to be selected.
>
> Finally it is possible to undefine USE_LEGACY in ftlcdfil.c, so that it is
> never used.

Looking at this possibility it turns filtering off when FT_LCD_FILTER_LEGACY is
used and calls FT_THROW (which would have some impact for all the text
rendered). I would need to change the code to set the default filter in
FT_Library_SetLcdFilter() in this case.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Marek Kašík  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
          Component|freetype                    |cairo
           Assignee|[e-mail]           |[e-mail]

--- Comment #24 from Marek Kašík  ---
Thinking about this little more, I'm reassigning this bug to cairo. There
exists good default value in freetype but cairo developers decided to set the
legacy filter as a default LCD filter in the past. This does not work well in
most scenarios but it does not mean that I should disable it explicitly.

Lets discuss this in freetype context once the new types of displays are
supported by freetype.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #25 from David  ---
(In reply to David from comment #22)
> Could someone quickly confirm with:
>
> echo "Xft.lcdfilter: lcdlight" >>"$HOME/.Xresources"
>
> and:
>
> freetype-2.9.1-6.fc29
>
> On a vanilla install of Fedora 29 font rendering will be correct, as it was
> with the freeworld package on Fedora 28? Thanks.

I am answering my own question, it works perfectly so long as you set
anti-aliasing to subpixel in tweaks... which is not obvious, so that needs
fixing if this is meant to be the new default.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Marek Kašík  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |MODIFIED
   Fixed In Version|                            |cairo-1.16.0-2.fc29

--- Comment #26 from Marek Kašík  ---
Hi,

I've asked Matthias Clasen whether I could assign this to myself and he agreed.
So I've pushed Nikolaus' patch to Fedora and will create an update for Fedora
29 for this bug.

Thank you all for your help with this.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #27 from Fedora Update System  ---
cairo-1.16.0-2.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-3a195026f5

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Michael Catanzaro  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #28 from Michael Catanzaro  ---
Hi Marek, I just announced a (totally unrelated) cairo CVE. I was going to add
the patch and do a new build, but I saw you just submitted this update a couple
hours ago, so seems best to coordinate with you, right?

TL;DR we need https://gitlab.freedesktop.org/cairo/cairo/merge_requests/5.patch
on F29 and rawhide, CVE-2018-19876. Can you add it to this update, please?

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Marek Kašík  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|[e-mail]             |[e-mail]

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #29 from Marek Kašík  ---
(In reply to Michael Catanzaro from comment #28)
> Hi Marek, I just announced a (totally unrelated) cairo CVE. I was going to
> add the patch and do a new build, but I saw you just submitted this update a
> couple hours ago, so seems best to coordinate with you, right?
>
> TL;DR we need
> https://gitlab.freedesktop.org/cairo/cairo/merge_requests/5.patch on F29 and
> rawhide, CVE-2018-19876. Can you add it to this update, please?

Hi,

since this is also related to freetype and the patch is quite straightforward
I'll add it there and will edit the update.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

Jonathan S  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                   |                            |m

--- Comment #30 from Jonathan S  ---
I've applied the fix from comment 27 (from koji).
(Note that only cairo-1.16.0-2.fc29.x86_64 and
cairo-gobject-1.16.0-2.fc29.x86_64 were updated as the others rpm's were not
present.)

It solved the problem except on firefox. Given Nikolaus's comment 14, I'm
guessing that this needs a separate fix.

I'm using a standard Fedora 29 Cinnamon spin, fully updated (as of now,
2018-12-07). Nikolaus's fix from comment 20 of 'ln -s
/usr/share/fontconfig/conf.avail/11-lcdfilter-light.conf /etc/fonts/conf.d/'
fixes the problem both before and after the update to cairo-1.16.0-2, even on
firefox.

Note that the Cinnamon spin (and possibly others) have a default of slight
hinting and subpixel (shown as 'rgba') antialiasing, so Cinnamon users are
seeing very bad colour fringing since the problem arose. So perhaps the
priority on this bug should be raised.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #31 from Kevin Kofler  ---
Raising the priority is pointless now that there is already a fix in
updates-testing, it will get out to stable very soon (especially now that it is
being bundled with a security update). You can leave positive Bodhi (Fedora
update system) feedback ("karma") for the update from updates-testing if you
want it to go to stable more quickly.

As for Firefox, you should probably file a separate bug against it.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #32 from Christian Stadelmann  ---
(In reply to David from comment #22)
> Could someone quickly confirm with:
>
> echo "Xft.lcdfilter: lcdlight" >>"$HOME/.Xresources"
>
> and:
>
> freetype-2.9.1-6.fc29
>
> On a vanilla install of Fedora 29 font rendering will be correct, as it was
> with the freeworld package on Fedora 28? Thanks.

Should this have any effect on Wayland at all? I am seeing the bug with Wayland
applications too and I doubt they are related to this config option.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #33 from Christian Stadelmann  ---
(In reply to Nikolaus Waxweiler from comment #20)
> Aaaaah! Yes, I remember now that you need to explicitly set the LCD filter
> for cairo. This bit me years ago, a simple `sudo ln -s
> /usr/share/fontconfig/conf.avail/11-lcdfilter-light.conf /etc/fonts/conf.d/`
> fixes it.

This does not help with cairo-1.16.0-3.fc29.x86_64 and subpixel hinting (rgba).

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #34 from Kevin Kofler  ---
cairo-1.16.0-3.fc29.x86_64 sets the correct LCD filter by default (that's what
the change in cairo-1.16.0-2.fc29.x86_64 was for), so it is normal that setting
it manually has no effect.

If you are still not happy with the result, you will probably just have to
disable subpixel antialiasing altogether. Subpixel antialiasing necessarily has
to play with the colors of the pixels.

[Bug 1645763] ClearType enablement: strong color fringing that is not present in vanilla build from freetype git

https://bugzilla.redhat.com/show_bug.cgi?id=1645763

--- Comment #35 from Christian Stadelmann  ---
(In reply to Kevin Kofler from comment #34)
> cairo-1.16.0-3.fc29.x86_64 sets the correct LCD filter by default (that's
> what the change in cairo-1.16.0-2.fc29.x86_64 was for), so it is normal that
> setting it manually has no effect.

Oh, that makes sense, thanks for the hint.
> If you are still not happy with the result, you will probably just have to
> disable subpixel antialiasing altogether. Subpixel antialiasing necessarily
> has to play with the colors of the pixels.

Subpixel antialiasing is still way worse than the freetype-freeworld solution
from rpmfusion on Fedora 28. The rpmfusion/freeworld solution looked good, but
both the new cairo-1.16.0-2.fc29.x86_64 subpixel antialiasing and the grayscale
antialiasing do not as they do not give sharp edges. The
cairo-1.16.0-2.fc29.x86_64 subpixel antialiasing is exaggerated too much to be
comfortable to look at. Is it possible that it is being applied twice?