Bug 1645763 - ClearType enablement: strong color fringing that is not present in vanilla build from freetype git
Summary: ClearType enablement: strong color fringing that is not present in vanilla bu...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: cairo
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-03 13:24 UTC by Nikolaus Waxweiler
Modified: 2019-03-26 22:04 UTC (History)
23 users (show)

Fixed In Version: cairo-1.16.0-2.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-10 23:19:57 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Scrrenshot of package and git FreeType font rendering (1.75 MB, application/zip)
2018-11-03 13:24 UTC, Nikolaus Waxweiler
no flags Details
Qt5 screenshot of subpixel rendering with freetype-freeworld (91.05 KB, image/png)
2018-11-05 22:13 UTC, Nikolaus Waxweiler
no flags Details
Example screenshot of Gtk3 application (29.51 KB, image/png)
2018-11-05 22:15 UTC, Nikolaus Waxweiler
no flags Details
white text on black background (117.60 KB, image/png)
2018-11-08 10:38 UTC, Dawid Zych
no flags Details
Qt5 OTF font rendering (492.92 KB, image/png)
2018-11-09 21:44 UTC, Nikolaus Waxweiler
no flags Details
A screenshot of nautilus running in a GNOME/Wayland session on Fedora 29 (57.55 KB, image/png)
2018-12-11 23:23 UTC, Christian Stadelmann
no flags Details

Description Nikolaus Waxweiler 2018-11-03 13:24:00 UTC
Created attachment 1500899 [details]
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.

Comment 1 Kevin Kofler 2018-11-03 14:13:55 UTC
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.

Comment 2 Kevin Kofler 2018-11-03 14:24:54 UTC
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.

Comment 3 Nikolaus Waxweiler 2018-11-03 15:22:58 UTC
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.

Comment 4 Christian Stadelmann 2018-11-04 12:10:19 UTC
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.

Comment 5 Nikolaus Waxweiler 2018-11-04 12:26:08 UTC
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.

Comment 6 David H. Gutteridge 2018-11-04 23:16:06 UTC
(Adding myself to CC list for visibility, this is significant for me, too.)

Comment 7 Kevin Kofler 2018-11-05 00:50:29 UTC
(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?h=5.6&id=748aa6b06462804a9671997302df292ae9788d5c

Qt 4 is patched in Fedora with the same change:
https://src.fedoraproject.org/cgit/rpms/qt.git/tree/qt-x11-opensource-src-4.5.1-enable_ft_lcdfilter.patch
(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!

Comment 8 Nikolaus Waxweiler 2018-11-05 22:10:18 UTC
A quick LD_PRELOAD test with https://download1.rpmfusion.org/free/fedora/releases/29/Everything/x86_64/os/repoview/freetype-freeworld.html 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?

Comment 9 Nikolaus Waxweiler 2018-11-05 22:13:24 UTC
Created attachment 1502223 [details]
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).

Comment 10 Nikolaus Waxweiler 2018-11-05 22:15:56 UTC
Created attachment 1502224 [details]
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.

Comment 11 Kevin Kofler 2018-11-05 22:35:14 UTC
So this looks like a Gtk3/Cairo bug, should we reassign it?

Comment 12 Nikolaus Waxweiler 2018-11-06 00:01:49 UTC
Dunno, maybe let's an see what happens 😁

Comment 13 Marek Kašík 2018-11-07 17:08:24 UTC
Hi, I'm looking at this issue (I've returned back to the office today). But I don't have a conclusion yet.

Comment 14 Nikolaus Waxweiler 2018-11-07 20:20:03 UTC
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?

Comment 15 Alexei Podtelezhnikov 2018-11-07 21:23:48 UTC
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.

Comment 16 Alexei Podtelezhnikov 2018-11-07 21:59:46 UTC
Ahhh.. Behdad Esfahbod pointed to this

https://azure.microsoft.com/en-us/blog/microsoft-joins-open-invention-network-to-help-protect-linux-and-open-source/

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

Comment 17 Dawid Zych 2018-11-08 10:38:59 UTC
Created attachment 1503296 [details]
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&num=1

Comment 18 Marek Kašík 2018-11-09 17:26:58 UTC
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/7a023a62f7517ad0d54f4d59c99909fadcc05e82 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).

Comment 19 Alexei Podtelezhnikov 2018-11-09 18:46:58 UTC
Please do not re-start the debate about filters. This has been thoroughly studied and published:
https://pdfs.semanticscholar.org/15e7/43f090862d29ca3159f79aee85b49b029a04.pdf

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.

Comment 20 Nikolaus Waxweiler 2018-11-09 21:44:03 UTC
Created attachment 1503858 [details]
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.

Comment 21 Nikolaus Waxweiler 2018-11-11 12:33:39 UTC
https://gitlab.freedesktop.org/cairo/cairo/merge_requests/1

Comment 22 David 2018-11-11 16:13:16 UTC
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.

Comment 23 Marek Kašík 2018-11-13 13:18:37 UTC
(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.

Comment 24 Marek Kašík 2018-11-19 13:37:17 UTC
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.

Comment 25 David 2018-11-19 15:16:18 UTC
(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.

Comment 26 Marek Kašík 2018-12-07 14:47:23 UTC
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.

Comment 27 Fedora Update System 2018-12-07 14:49:02 UTC
cairo-1.16.0-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3a195026f5

Comment 28 Michael Catanzaro 2018-12-07 17:25:48 UTC
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?

Comment 29 Marek Kašík 2018-12-07 18:39:12 UTC
(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.

Comment 30 Jonathan S 2018-12-07 22:24:01 UTC
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.

Comment 31 Kevin Kofler 2018-12-08 03:57:26 UTC
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.

Comment 32 Christian Stadelmann 2018-12-08 14:06:11 UTC
(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.

Comment 33 Christian Stadelmann 2018-12-08 14:15:49 UTC
(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).

Comment 34 Kevin Kofler 2018-12-08 15:14:14 UTC
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.

Comment 35 Christian Stadelmann 2018-12-08 16:53:13 UTC
(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?

Comment 36 Randy Barlow 2018-12-10 23:19:57 UTC
An update associated with this bug has been pushed to stable.

Comment 37 Marek Kašík 2018-12-11 13:27:46 UTC
(In reply to Christian Stadelmann from comment #35)
> (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?

Under which application do you see the problem? I think that Thunderbird and Firefox have their own cairo so the system one does not solve the issue.
Could you attach a screenshot so I can see the problem?

Comment 38 Randy Barlow 2018-12-11 17:04:09 UTC
A Fedora update associated with this bug has been pushed to the stable repository.

Comment 39 Christian Stadelmann 2018-12-11 23:23:38 UTC
Created attachment 1513551 [details]
A screenshot of nautilus running in a GNOME/Wayland session on Fedora 29

(In reply to Marek Kašík from comment #37)
> Under which application do you see the problem? I think that Thunderbird and
> Firefox have their own cairo so the system one does not solve the issue.
> Could you attach a screenshot so I can see the problem?

Under both a GNOME/Xorg and a GNOME/Wayland desktop, it does seem to affect any application: Firefox (firefox-wayland and the default firefox builds), any GNOME application such as Nautilus, Evolution, GEdit; GNOME shell; Different Qt5 applications, …

Comment 40 Artem 2018-12-12 06:30:55 UTC
This update doesn't fixed anything. Font rendering is still ugly as hell for me after this updates. cairo-1.16.0-3.fc29 version.

Comment 41 Artem 2018-12-12 06:44:36 UTC
Subpixel font rendering in GTK and Qt apps now looks OK. Ugly font rendering still only in Firefox.

Comment 42 Randy Barlow 2018-12-14 20:41:19 UTC
A Fedora update associated with this bug has been pushed to the stable repository.

Comment 43 Marek Kašík 2019-01-03 10:59:43 UTC
(In reply to Christian Stadelmann from comment #39)
> Created attachment 1513551 [details]
> A screenshot of nautilus running in a GNOME/Wayland session on Fedora 29
> 
> (In reply to Marek Kašík from comment #37)
> > Under which application do you see the problem? I think that Thunderbird and
> > Firefox have their own cairo so the system one does not solve the issue.
> > Could you attach a screenshot so I can see the problem?
> 
> Under both a GNOME/Xorg and a GNOME/Wayland desktop, it does seem to affect
> any application: Firefox (firefox-wayland and the default firefox builds),
> any GNOME application such as Nautilus, Evolution, GEdit; GNOME shell;
> Different Qt5 applications, …

It looks like you use "none" LCD filtering from the screenshot. But it is strange that you see this in so many different environments. I guess that you have it set globally in a place like "/etc/fonts/conf.d/". Does any of the files there contain "lcdnone" string?
Do you see the problem under a new user?

Comment 44 Christian Stadelmann 2019-01-07 22:01:02 UTC
(In reply to Marek Kašík from comment #43)
> It looks like you use "none" LCD filtering from the screenshot. But it is
> strange that you see this in so many different environments. I guess that
> you have it set globally in a place like "/etc/fonts/conf.d/". Does any of
> the files there contain "lcdnone" string?

No. Also, `rpm -Va /etc/fonts` does not return any modifications there.

> Do you see the problem under a new user?

No, I don't. So the problem is with my user account. Thanks for the hint!

Comment 45 Christian Stadelmann 2019-01-07 22:31:46 UTC
After setting /org/gnome/settings-daemon/plugins/xsettings/rgba-order to 'rgba' (instead of the default, 'rgb') and logout+login, everything works fine BUT gnome-shell.

Then, I deleted the file ~/.config/fontconfig/fonts.conf, which set the lcdfilter to lcdnone.

Now fonts in all the apps and gnome-shell chrome and overview look ok (not perfectly sharp but acceptable). Except for the gnome-shell-extension "Desktop Icons" where the issue still persists.

Comment 46 Marek Kašík 2019-01-08 14:34:27 UTC
(In reply to Christian Stadelmann from comment #45)
> After setting /org/gnome/settings-daemon/plugins/xsettings/rgba-order to
> 'rgba' (instead of the default, 'rgb') and logout+login, everything works
> fine BUT gnome-shell.

If I set rgba then I get whole-pixel rendering instead of subpixel (it at least seems so since the text is grayscale when zoomed).

> Then, I deleted the file ~/.config/fontconfig/fonts.conf, which set the
> lcdfilter to lcdnone.
> 
> Now fonts in all the apps and gnome-shell chrome and overview look ok (not
> perfectly sharp but acceptable). Except for the gnome-shell-extension
> "Desktop Icons" where the issue still persists.

I've just tested the "Desktop Icons" extension in VM and it seems that it reacts correctly to all the changes I do. So I don't know what can cause this. Maybe screenshot would help.

Comment 47 Will Dietz 2019-01-29 17:20:29 UTC
FWIW I believe "rgba" is not a valid value for "rgba-ordering" (or "gtk-xft-rgba" or Xresource "Xft.rgba" or fontconfig "rgba").

For example:

https://gitlab.gnome.org/GNOME/gtk/blob/d9d487962307fe935d35d5397c552e637bcf6ca9/gtk/gtksettings.c#L2083

https://gitlab.freedesktop.org/fontconfig/fontconfig/blob/586e35450e9ca7c1dc647ceb9d75ac8ed08c5c16/doc/fontconfig-user.sgml#L125

Not especially helpful :( but it's likely whatever behavior setting to "rgba" causes is the same as if you typed nonsense, and maybe as "none" although not sure.


Note You need to log in before you can comment on or make changes to this bug.