[Bug 904015] New: font aliasing broken under KDE
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 Bug ID: 904015 Summary: font aliasing broken under KDE Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: KDE4 Workspace Assignee: kde-maintainers@suse.de Reporter: vkrevs@yahoo.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 612480 --> http://bugzilla.opensuse.org/attachment.cgi?id=612480&action=edit opensuse_13.1_kde_font_settings1.png For a very long time (since openSUSE 11.x), my KDE font settings had been set up to use Tahoma 8 as the main font, with enabled anti-aliasing and excluding range 0.0-8.0. This resulted in beautiful fonts in all KDE and GTK apps (see attached opensuse_13.1_kde_font_settings1.png file). Today I had upgraded to openSUSE 13.2 from 13.1. As a result, rendering of Tahoma 8 has changed in all applications but Google Chrome (see attached opensuse_13.2_kde_font_settings1.png file) and is very ugly compared to how it was in 13.1. Looks like BCI is not used for font sizes in the excluded range. I have tried rebuilding the freetype2 package with enable_subpixel_rendering set to 1 to no avail, also tried changing BYTECODE_BW_MAX_PIXEL from 0 to 8 in /etc/sysconfig/fonts-config to no avail as well. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 --- Comment #1 from Vadim Krevs <vkrevs@yahoo.com> --- Created attachment 612481 --> http://bugzilla.opensuse.org/attachment.cgi?id=612481&action=edit opensuse_13.2_kde_font_settings1.png -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 --- Comment #2 from Vadim Krevs <vkrevs@yahoo.com> --- I have found a "workaround" - replace the contents of /usr/share/fontconfig/conf.avail, /usr/share/fonts-config/conf.avail, /etc/fonts/conf.d shipped with 13.2 with what was there in openSUSE 13.1, re-ran fonts-config, restarted X, and pretty fonts are back. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c3 Tomáš Chvátal <tchvatal@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |opensuse-kde-bugs@opensuse. | |org Assignee|kde-maintainers@suse.de |pgajdos@suse.com --- Comment #3 from Tomáš Chvátal <tchvatal@suse.com> --- Maybe some bug in fonts-config? @Petr: any thoughts? Can't reproduce on Leap and TW I have here. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c29 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #29 from Marguerite Su <i@marguerite.su> --- Hi, Sorry for the late reply after half a year (I thought it was not assigned to me before) I am not that expert but I know how to stand on the giants' shoulders. I just diff-ed the "without workaround" and "with workaround" outputs. There were noises of course, the "(w)" and "(s)" took a lot of space. After reading the source code, I know they are called "FcValudeBindingWeak (w)" and "FcValueBindingStrong (s)", So they're unrelated to the issue here. Then I found what your "workaround" actually is: antialias: True And this explains why your Tahoma font looks like with scratches on it. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c30 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS --- Comment #30 from Marguerite Su <i@marguerite.su> --- $ grep -r "Tahoma" fonts.conf_13.2_good (the one the reporter provided in comment#18) ./usr/share/fontconfig/conf.avail/11-suse-hinting.conf ./usr/share/fontconfig/conf.avail/58-suse-post-user.conf ./usr/share/fontconfig/conf.avail/65-fonts-persian.conf ./usr/share/fontconfig/conf.avail/12-suse-hinting-bc.conf ./usr/share/fontconfig/conf.avail/60-latin.conf ./usr/share/fonts-config/conf.avail/12-suse-hinting-bc.conf ./usr/share/fonts-config/conf.avail/10-group-tt-hinted-fonts.conf (Everything I said below can be found in "fonts-config"/"fontconfig" packages in 13.1/13.2 repository on build.opensuse.org) 65-fonts-persian.conf and 60-latin.conf are from fontconfig upstream. there's no difference between 2.11.0 and 2.11.1 10-group-tt-hinted-fonts.conf is from infinality. it just put fonts into "TT Instructed Font" category. 58-suse-post-user.conf just disables autohint for Tahoma if its antialias is disabled. not related to our issue. 12-suse-hinting-bc.conf is from 13.1's fonts-config, it basically does one thing: disable antialais and autohint for Tahoma if its pixelsize is less than or equal to 0 (apparently, it means "do nothing"). So the only thing left is 11-suse-hinting.conf, it does the same thing as 12-suse-hinting-bc.conf, but take a look at the beginning: <!-- Using hinting=true, hintstyle=hintfull and antialias=true is a good default for most fonts. Match on "pattern" for the default, not on "font" to make it easier to override the default using FcPatternDel() and FcPatternAdd...() (see bugzilla #104365). --> <match target="pattern"> <edit name="hinting"> <bool>true</bool> </edit> <edit name="antialias"> <bool>true</bool> </edit> </match> In 13.1 (this file is missing from 13.2), it set hinting, antialias to true for all fonts at first, and tries to disable for those non-fit fonts later. But as I said, none of the later configurations is able to disable antialias for Tahoma. But in 13.2, we let some former self-maintained configurations go. $ grep -r "antialias" ./usr/share/fonts-config/conf.avail (from fonts-config in 13.2, as I said, no need to research on configurations provided by fontconfig itself) ./11-base-rendering.conf ./12-tt-monospace-rendering.conf ./13-selective-rendering-ipa.conf ./60-family-prefer.conf 12-tt-monospace-rendering.conf doesn't apply to Tahoma since it's not a monospace font. 13-selective-rendering-ipa.conf only applies to IPA font which is a Japanese font. 60-family-prefer.conf has "antialias" inside its comments. Let's take a look at 11-base-rendering.conf: <!-- font smooth or don't font smooth --> <match target="font"> <!-- this test should not be needed, as antialiasing is done only for outlines, but workarounds Qt5 issue, see bug 866705 --> <test name="outline"> <bool>true</bool> </test> <edit name="antialias" mode="assign"> <bool>true</bool> </edit> </match> So in 13.2, we only enable antialias for outline fonts. But Tahoma is an outline font, right? And I think here's the precise description of the bug: "Tahoma", an outlined font, didn't get its antialias enabled by fontconfig. Thanks Marguerite -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c31 --- Comment #31 from Marguerite Su <i@marguerite.su> --- Using "FC_DEBUG=4 kwrite > antialias.txt", I can tell that our match for all outline fonts is wrong. <match target="font"> <!-- this test should not be needed, as antialiasing is done only for outlines, but workarounds Qt5 issue, see bug 866705 --> <test name="outline"> <bool>true</bool> </test> <edit name="antialias" mode="assign"> <bool>true</bool> </edit> </match>
From upstream: https://www.freedesktop.org/software/fontconfig/fontconfig-user.html
<match target="pattern"> This element holds first a (possibly empty) list of <test> elements and then a (possibly empty) list of <edit> elements. Patterns which match all of the tests are subjected to all the edits. If 'target' is set to "font" instead of the default "pattern", then this element applies to the font name resulting from a match rather than a font pattern to be matched. Let me explain it in another simple way: If you use <match target="font">, you have to write a "test" condition that actually matches "one" font. (you see there's no "the font names" but "the font name"). We don't match any font in test, so the property "outline" is applied to null/empty. Then the edit block returns empty, too. So here's the fix: <match target="pattern"> <!-- this test should not be needed, as antialiasing is done only for outlines, but workarounds Qt5 issue, see bug 866705 --> <test name="outline"> <bool>true</bool> </test> <edit name="antialias" mode="assign"> <bool>true</bool> </edit> </match> Remember, any match that wish to have multiple possible values (an array) must use the "pattern" target instead of "font" target. All such matches in fontconfig/fonts-config need to be fixed. Marguerite -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c32 --- Comment #32 from Marguerite Su <i@marguerite.su> --- So there're two bugs here actually, both need to be fixed in 13.1+ systems that is Leap 42.1, Leap 42.2, Leap 42.3 and openSUSE Tumbleweed. 1. disable antialais and autohint for Tahoma if its pixelsize is less than or equal to 0 (means do nothing). The <double>0</double> here needs to be increased to a reasonable value. I think its logic is wrong, too. The bigger the pixel size, let's say 96px, the more clear and less blurred the font actually is. So it should be pixel sizes less than or equal to a specific value that need antialias. we should add it instead of remove it unless it is verified to have embeded bitmaps. autohint is another story. if there is hinting information provided by the font itself, BCI should be used. we should try to only apply autohint to the fonts without good hinting information. it is not related with pixel size, at all. 2. all existing matches that intended to have multiple possible values but wrongly used "font" as match target should be corrected to the "pattern" target. So please wait for updates. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|font aliasing broken under |outlined font, didn't get |KDE |its antialias enabled by | |fontconfig -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|outlined font, didn't get |outlined fonts didn't get |its antialias enabled by |their antialias enabled by |fontconfig |fontconfig in openSUSE 13.2 | |and above -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P4 - Low |P2 - High Version|13.2 |Leap 42.3 Component|KDE Workspace (Plasma) |Basesystem Hardware|Other |All Found By|--- |Community User Target Milestone|--- |Leap 42.3 Severity|Normal |Critical OS|Other |All -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c33 --- Comment #33 from Vadim Krevs <vkrevs@yahoo.com> --- Thank you for this - much appreciated. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c34 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(vkrevs@yahoo.com) --- Comment #34 from Marguerite Su <i@marguerite.su> --- please test if the fonts-config in https://build.opensuse.org/package/show/M17N/fonts-config solves your problem (definitely will) tumbleweed submitted https://build.opensuse.org/request/show/452791 leap 42.1/42.2 update sent: https://build.opensuse.org/request/show/452795 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c37 --- Comment #37 from Marguerite Su <i@marguerite.su> --- Hi, Petr, Do you mean this: pattern: many fonts -> edit -> edited many fonts -> match -> matched fonts font: many fonts -> match -> matched fonts -> edit -> edited matched fonts Am I correct? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c38 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(vkrevs@yahoo.com) | --- Comment #38 from Marguerite Su <i@marguerite.su> --- After a careful view in 'FC_DEBUG=4 kwrite > antialias.txt", I found my modification will lead to no match but the previous <match target="font"> will not. So apparently I gave a wrong fix. whatever Petr said looks correct. And interestingly, I found on openSUSE Tumbleweed, the "Tahoma" actually has "antialias" enabled. So TW is not affected by this problem. it does everything as expected. Maybe we really need to mount a 13.2 ISO. Marguerite -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c41 --- Comment #41 from Vadim Krevs <vkrevs@yahoo.com> --- Yes, it was with sizes <=8. I have tried the updated fontconfig in a clean Leap 42.2 inside virtual box but it did not result in Tahoma font rendering like in the first attachment. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c46 --- Comment #46 from Marguerite Su <i@marguerite.su> --- Hi, Petr, Breaking news! I got it reproduced! First, I followed your instruction in comment#45 on a 1320 box, but the looking is still good, and is exactly what you/the reporter want. Second I cleaned up all your stuff. And I emulated the reporter's setting. So I got it reproduced. (see attachment in the next comment) It turns out that KDE will add these lines into ~/.config/fontconfig/fonts.conf: <match target="font"> <edit mode="assign" name="rgba"> <const>rgb</const> </edit> </match> <match target="font"> <edit mode="assign" name="hinting"> <bool>true</bool> </edit> </match> <match target="font"> <edit mode="assign" name="hintstyle"> <const>hintfull</const> </edit> </match> <match target="font"> <edit mode="assign" name="antialias"> <bool>true</bool> </edit> </match> <match target="font"> <test compare="more_eq" name="size" qual="any"> <double>0</double> </test> <test compare="less_eq" name="size" qual="any"> <double>8</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match> <match target="font"> <test compare="more_eq" name="pixelsize" qual="any"> <double>0</double> </test> <test compare="less_eq" name="pixelsize" qual="any"> <double>11</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match> It is intended. If I cleaned these settings. The "Fonts" section of KDE Settings will be reset too. And the 0-11 antialias false is intended too. Not done by myself or my fault operations. That is you exclude range 0-8, KDE will automatically add another 0-11 entry for you. And "fc-match -v Tahoma:size=8" returns: size: 8(f)(s) pixelsize: 8.33333(f)(s) antialias: False(w) hintstyle: 3(i)(w) hinting: True(w) autohint: False(w) The "antialias" is false here. Remove the local fonts.conf, then: size: 8(f)(s) pixelsize: 8.33333(f)(s) antialias: True(w) hintstyle: 3(i)(w) hinting: True(w) autohint: False(w) And I successfully isolated the problem lays here: <match target="font"> <test compare="more_eq" name="size" qual="any"> <double>0</double> </test> <test compare="less_eq" name="size" qual="any"> <double>8</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match> KDE's implementation of "exclude range" actually excluded the edge values too. Maybe in 13.1, the implementation was not. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c47 --- Comment #47 from Marguerite Su <i@marguerite.su> --- Created attachment 712625 --> http://bugzilla.opensuse.org/attachment.cgi?id=712625&action=edit my emulation result for the reporter's behavior -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c48 --- Comment #48 from Marguerite Su <i@marguerite.su> --- So it seems: We misunderstood meanings of the reporter: he may want Tahoma with size 8 has antialias "disabled". because his behavior actually did so. Or his success in 13.1 made him think the exclude range option in KDE does not have the edge value included, eg 0 <= range < 8, which is not the case. Or KDE changed their implementations from 13.1's version to 13.2's version. I need to investigate KDE's git commit logs to be sure. Marguerite. BTW: Even in TW and KDE Plasma 5, it still appends such settings to ~/.config/fontconfig/fonts.conf if you set up font rendering using System Settings. And the: <match target="font"> <test compare="more_eq" name="pixelsize" qual="any"> <double>0</double> </test> <test compare="less_eq" name="pixelsize" qual="any"> <double>11</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> is still appended too. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c49 --- Comment #49 from Marguerite Su <i@marguerite.su> --- https://cgit.kde.org/plasma-desktop.git/commit/kcms/fonts/kxftconfig.cpp?id=... The KXftConfig::applyExcludeRange actually set the "less_eq" things. I need to find a change from "less" to "less_eq" to prove my theory. But unluckily the log just backs to 2014.3 while 13.1 was released in 2013 But I can still download the tarball from OBS to verify. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c50 --- Comment #50 from Marguerite Su <i@marguerite.su> --- kxftconfig.cpp in kdebase4-workspace 4.11.2 in 13.1 is the same with the one in kdebase4-workspace 4.11.12 in 13.2. I am starting to think the reporter triggered a false alarm, or it's not antialias related at all. I will try on my 13.2 virtualbox tomorrow to see how I can change the broken rendering good again. That may help. Marguerite -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c52 --- Comment #52 from Marguerite Su <i@marguerite.su> --- @Petr, Yes, in the reporter's settings, he forced DPI to 96. But other things he reported are now weird to me. He told us "He had been used Tahoma size=8 with enabled antialias"...but his exclude range settings would definitely disable antialias for size=8 on both openSUSE 13.1 and openSUSE 13.2. Then the scratched looking is predictable. There's no bug existed unless he means "both without antialias, openSUSE 13.1 displayed clear and sharp while openSUSE 13.2 was not". That'll be an embededbitmap issue. there'll be little things the rendering engine can do antialias and autohint disabled, hinting is enabled, BCI rendering will be used. But even with closed-source sub-pixel rendering, it still needs antialias to make the font look sharp because sub-pixel rendering actually adds something grey, it'll be certainly blurred without antialias But does Tahoma have embededbitmap? Apparently not: $ fc-match -v Tahoma:size=8 embeddedbitmap: False(w) Marguerite -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c54 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #712625|0 |1 is obsolete| | --- Comment #54 from Marguerite Su <i@marguerite.su> --- Created attachment 712766 --> http://bugzilla.opensuse.org/attachment.cgi?id=712766&action=edit comparation using gimp @Petr I am afraid this is an invalid bug. Fresh install of openSUSE 13.1 and openSUSE 13.2 in Virtualbox, both used the same Tahoma font and the same flavor (KDE Live as the reporter used KDE) Both used the same settings as the reporter. That is, All fonts set to Tahoma size=8 except for Monospace and Title with rendering options "0.0pt - 8.0pt, RGB, full" and forced DPI "96". I took screenshots on both systems. They look the same with the same settings. And the "fc-match -v Tahoma:size=8" results the same too. It means even if there're differences between 13.1/13.2 in system fontconfigs, they achieved the same thing. I overlaped the screenshot taken on 13.1 to the screenshot taken on 13.2 with GIMP. The rendered glyphs are even the same too. It will get rid of the minor "effects" that the reporter can see while I can't. So they are identically the same. I think we were mis-guided. The only difference between the users' screenshots of 13.1 and 13.2 is that one of them had antialias enabled (from the look, and the diff I previously made). But the reporter's settings can not prove his theory. I have proved that the underlying technology didn't change between KDE release, which is if you set exclude range from 0.0pt to 8.0pt, Tahoma will have no antialias on size 8 for sure. So, unless the reporter can provide further proof, I think we can close this bug as invalid. What do you think, Petr? Marguerite -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=904015 http://bugzilla.opensuse.org/show_bug.cgi?id=904015#c74 Marguerite Su <i@marguerite.su> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|i@marguerite.su |pgajdos@suse.com --- Comment #74 from Marguerite Su <i@marguerite.su> --- reassigned to Petr. I didn't find any problem related to the system. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com