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.
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.
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.
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.
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.
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.
(Adding myself to CC list for visibility, this is significant for me, too.)
(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!
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?
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).
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.
So this looks like a Gtk3/Cairo bug, should we reassign it?
Dunno, maybe let's an see what happens 😁
Hi, I'm looking at this issue (I've returned back to the office today). But I don't have a conclusion yet.
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?
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.
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.
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
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).
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.
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.
https://gitlab.freedesktop.org/cairo/cairo/merge_requests/1
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.
(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.
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.
(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.
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.
cairo-1.16.0-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3a195026f5
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?
(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.
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.
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.
(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.
(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).
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.
(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?
An update associated with this bug has been pushed to stable.
(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?
A Fedora update associated with this bug has been pushed to the stable repository.
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, …
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.
Subpixel font rendering in GTK and Qt apps now looks OK. Ugly font rendering still only in Firefox.
(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?
(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!
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.
(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.
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.