Bugzilla – Bug 904015
outlined fonts didn't get their antialias enabled by fontconfig in openSUSE 13.2 and above
Last modified: 2017-02-21 12:59:37 UTC
Created attachment 612480 [details] 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.
Created attachment 612481 [details] opensuse_13.2_kde_font_settings1.png
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.
Maybe some bug in fonts-config? @Petr: any thoughts? Can't reproduce on Leap and TW I have here.
What says $ fc-match -v Tahoma:size=5 for the ordinary user on original system (~ without the workaround)?
Created attachment 658622 [details] Requested output of fc-match Attached.
autohint: False(w) Forcing authohint is turned off, so BCI should be used. What says the same command on 13.1 or when applying the workaround?
Needinfo for comment 6.
Sorry about the delay. I no longer have a 13.1 system, but on my 13.2 system with the workaround the output of "fc-match -v Tahoma:size=5" is identical to the one attached earlier.
Hmm, I am bit clueless then. Could you please try run (in both cases -- wrong and right) FC_DEBUG=1 your-prg-here > log in both cases? your-prg-here should be a less complex as possible program that exposes the issue. You need to navigate the program to actually show the font by the shortest way and then quit it the shortest way. The diff could be interesting for us, please attach both logs here.
Created attachment 659783 [details] Output of "FC_DEBUG=1 systemsettings" on 13.2 without workaround
Created attachment 659784 [details] Output of "FC_DEBUG=1 systemsettings" on 13.2 with workaround
Each time I started konsole, and ran "FC_DEBUG=1 systemsettings" and then immediately closed systemsettings.
$ fc-match -v Tahoma:size=8 | grep pixelsize pixelsize: 8.33333(f)(s) But in your output is pixelsize: 11.57(f)(s) So it seems that you are not displaying font in range 0..8 while creating output in comment 10 and comment 11.
Umm, the font sizes in System Settings->Application Appearance->Fonts are set the same way as in the attachment in comment 1. Here is the output from 2 consecutive commands in konsole: vadymk@firefly /tmp $ fc-match -v Tahoma:size=8 | grep pixelsize pixelsize: 8.33333(f)(s) vadymk@firefly /tmp $ FC_DEBUG=1 systemsettings | grep pixel pixelsize: 11.57(f)(s) pixelsize: 11.57(f)(s) pixelsize: 11.57(f)(s) I don't know how to explain the difference (but all fonts/sizes/rendering details used by systemsettings appear to be the same fonts/sizes/rendering details used elsewhere in KDE apps).
BTW, I've upgraded my office desktop from 13.2 to 42.1 and basically ended up with the same situation as described in comment 1 (only 42.1 additionally completely ignored all font settings I had in 13.2 and overrode them with its own defaults).
(In reply to Vadim Krevs from comment #14) > Umm, the font sizes in System Settings->Application Appearance->Fonts are > set the same way as in the attachment in comment 1. I thought so, weird. Perhaps it can't be helped another way. Could you please figure out which fontconfig files are in play and then attach them here? FC_DEBUG=1024 systemsettings will tell you which ones. (In reply to Vadim Krevs from comment #15) > completely ignored all font settings I had in 13.2 and overrode them with > its own defaults). Well I do not know how KDE store their fontconfig settings and how it cooperate with distribution defaults. Distribution defaults has changed, yes, but user settings should remain. While it seems you are willing to play with your font settings a lot, I would suggest to create your own ~/.config/fontconfig/fonts.conf[1] to your needs. This settings can be written so that it is always prefered by correctly written fontconfig-aware applications. You will gather complete[2] control over displayed fonts in contrast of any font dialog you can imagine. I can guide you, if you want. [1] https://wiki.archlinux.org/index.php/Font_configuration [2] http://www.freedesktop.org/software/fontconfig/fontconfig-user.html
$ FC_DEBUG=1024 systemsettings FC_DEBUG=1024 Loading config file /etc/fonts/fonts.conf Scanning config dir /etc/fonts/conf.d Loading config file /etc/fonts/conf.d/10-group-tt-hinted-fonts.conf Loading config file /etc/fonts/conf.d/10-group-tt-non-hinted-fonts.conf Loading config file /etc/fonts/conf.d/10-rendering-options.conf Loading config file /etc/fonts/conf.d/10-scale-bitmap-fonts.conf Loading config file /etc/fonts/conf.d/11-base-rendering.conf Loading config file /etc/fonts/conf.d/11-suse-hinting.conf Loading config file /etc/fonts/conf.d/12-suse-hinting-bc.conf Loading config file /etc/fonts/conf.d/12-tt-monospace-rendering.conf Loading config file /etc/fonts/conf.d/13-selective-rendering-ipa.conf Loading config file /etc/fonts/conf.d/13-selective-rendering.conf Loading config file /etc/fonts/conf.d/16-suse-hintstyle.conf Loading config file /etc/fonts/conf.d/17-suse-bitmaps.conf Loading config file /etc/fonts/conf.d/18-suse-bitmaps-misc.conf Loading config file /etc/fonts/conf.d/20-unhint-small-vera.conf Loading config file /etc/fonts/conf.d/30-metric-aliases.conf Loading config file /etc/fonts/conf.d/30-urw-aliases.conf Loading config file /etc/fonts/conf.d/31-cantarell.conf Loading config file /etc/fonts/conf.d/31-metric-aliases-bw.conf Loading config file /etc/fonts/conf.d/40-nonlatin.conf Loading config file /etc/fonts/conf.d/45-latin.conf Loading config file /etc/fonts/conf.d/49-family-default.conf Loading config file /etc/fonts/conf.d/49-sansserif.conf Loading config file /etc/fonts/conf.d/50-suse-pre-user.conf Loading config file /etc/fonts/conf.d/55-local.conf Loading config file /etc/fonts/conf/56-user.conf Loading config file /home/vadymk/.config/fontconfig/fonts.conf Loading config file /home/vadymk/.fonts.conf Loading config file /etc/fonts/conf.d/58-family-prefer-local.conf Loading config file /etc/fonts/conf.d/58-suse-post-user.conf Loading config file /etc/fonts/conf.d/60-family-prefer.conf Loading config file /etc/fonts/conf.d/60-latin.conf Loading config file /etc/fonts/conf.d/61-wine-aliases.conf Loading config file /etc/fonts/conf.d/65-fonts-persian.conf Loading config file /etc/fonts/conf.d/65-nonlatin.conf Loading config file /etc/fonts/conf.d/69-unifont.conf Loading config file /etc/fonts/conf.d/70-reject.conf Loading config file /etc/fonts/conf.d/80-delicious.conf Loading config file /etc/fonts/conf.d/90-synthetic.conf
Created attachment 660326 [details] Tarball containing files referenced in comment 17
Output of "FC_DEBUG=1024 systemsettings" is in comment 17, referenced files are in attachment referenced in comment 18.
Clearing needinfo flag.
(In reply to Vadim Krevs from comment #14) > vadymk@firefly /tmp > $ fc-match -v Tahoma:size=8 | grep pixelsize > pixelsize: 8.33333(f)(s) > > vadymk@firefly /tmp > $ FC_DEBUG=1 systemsettings | grep pixel > pixelsize: 11.57(f)(s) > pixelsize: 11.57(f)(s) > pixelsize: 11.57(f)(s) Aha, I have not noticed you force dpi in kde settings. Anyway: I believe kde is writing /home/vadymk/.config/fontconfig/fonts.conf. (In reply to Vadim Krevs from comment #17) > $ FC_DEBUG=1024 systemsettings > Loading config file /home/vadymk/.config/fontconfig/fonts.conf > Loading config file /home/vadymk/.fonts.conf /home/vadymk/.fonts.conf is deprecated location, but they are identical, so it should not do any harm. It is there either from previous installation or kde is writing both to be sure it is applied (look at timestamps, and feel free to remove /home/vadymk/.fonts.conf completely if it is old). It is interesting, that the range is another then [0, 8] pt: <match target="font"> <test compare="more_eq" name="size" qual="any"> <double>0</double> </test> <test compare="less_eq" name="size" qual="any"> <double>7</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>12</double> </test> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match> But 11.57 fits [0, 12] px, so the font is later drawn black and white as desired.
Created attachment 660435 [details] tahoma font rendered without antialiasing for px <= 12 It seems that I am unable to reproduce the issue with firefox on Leap, as screenshot shows. The text is of 10 <= pixel size <= 15. First three rows are rendered black and white without artefacts. The only unpleasant output I get for italic text tahoma (small sizes, without antialiasing).
I also tried some GTK applications on leap and they do not evince any issue with hinting. Used <match target="pattern"> <edit mode="assign" name="family"> <string>tahoma</string> </edit> </match> in .config/fontconfig/fonts.conf to be sure tahoma is displayed everywhere.
Created attachment 660445 [details] a kde application also does not show artefacts I tried also random kde application I happen to have installed on my Tumbleweed system and it also does not expose the problem.
Tomáš: you tried also live KDE @ 42.1 and you failed to reproduce this problem, correct?
(In reply to Petr Gajdos from comment #25) > Tomáš: you tried also live KDE @ 42.1 and you failed to reproduce this > problem, correct? Yep. I was unable to trigger it...
I am no longer maintainer of fontconfig or fonts-config in opensuse.
and assigning to the new maintainer was too much work?
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.
$ 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
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
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.
Thank you for this - much appreciated.
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
(In reply to Marguerite Su from comment #31) > <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"). I do not understand it that way. 'pattern' changes entries in the pattern before matching the pattern to a real font. Then the matching of pattern to a one real font in the system happens which results in a pattern that correspons to only that font (incl. 'file' entry for example). Later, 'font' type changes are performed on entries in the pattern that corresponds to one font in the system, just before it is returned from the library. That means, for example, that: <match target="font"> <!-- hinting is on unconditionally, but that --> <!-- can be controlled via hintstyle (hintnone) --> <edit name="hinting" mode="assign"> <bool>true</bool> </edit> </match> says: 'for every real font pattern set hinting to true'. Or: <match target="font"> <test name="fontformat"> <string>CFF</string> </test> <edit name="autohint" mode="assign"> <bool>false</bool> </edit> </match> says: for every real font pattern, where fontformat=CFF, set autohint to false. That is because CFF are not supposed to be rendered by autohinter. That all sounds correct, because most likely 'fontformat' entry of the pattern is likely not filled in at all before matching to real font. And now: <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> This sounds correct to me to change font, again, because I think 'outline' will probably not part of the pattern before matching at all. Writing from top of my head, sorry If I overlooked something.
(I accepted a maintainer role of fontconfig/fonts-config together with simotek, so feel free to reassign back to me.)
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?
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
(In reply to Marguerite Su from comment #37) > 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 ((1)) pattern at the beginning is a request. For example, in $ fc-match -v sans:size=20 the pattern is 'sans:size=20' Fontconfig first applies <match target="pattern"> rules to this pattern, fx. <match target="pattern"> <test qual="any" name="family"> <string>sans</string> </test> <edit name="family" mode="assign" binding="same"> <string>sans-serif</string> </edit> </match> _edits_ sans to sans-serif. the pattern is then 'sans-serif:size=20'. Later, it applies <alias> [which is just syntactic sugar to <matrch target="pattern">] rules, e. g. from 60-family-prefer.conf. The pattern then looks for example like: "Roboto 'Noto Kufi Arabic' ... sans-serif ...":size=20' etc. These changes has to be done before matching. ((2)) Match. According to pattern created in ((1)), one font is chosen from the system. The pattern is filled in with final entries, e. g. file, charset, etc. ((3)) Now <match target="font"> rules are applied. For example rendering algorithm details need to be resolved here in my opinion as they depend on e. g. fontformat.
(In reply to Marguerite Su from comment #38) > And interestingly, I found on openSUSE Tumbleweed, the "Tahoma" actually has > "antialias" enabled. I guess the original problem (comment 0) Vadim has is different. Vadim would like to have Tahoma with size 8.0 rendered with antialiasing and Tahoma of size less then 8.0 rendered without antialiasing. Vadim, the problem is with the smaller sizes, correct? When a font has good built-in instructions (very few fonts), they are good to render with help of BCI (byte code interpreter). For small sizes, it can give nice sharp result when rendered without antialiasing. Question is, where the problem lies. BYTECODE_BW_MAX_PIXEL sysconfig variable was used for that purpose, but I need to look into it more.
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.
Needinfo on me so I do not forgot. I have much to do right now, I'll look into it later.
Ugh, with the priority and severity you had jumped over all the security bugs I ever had :).
(In reply to Petr Gajdos from comment #42) > Needinfo on me so I do not forgot. I have much to do right now, I'll look > into it later. I'll also try and have a look, mostly as a learning experience, whether I get anywhere before you is another question though.
Let's try step by step on 42.2 leap system. I do not have access to Tahoma font, I will try Arial which is downloaded by fetchmsttfonts instead. (1) Let us first look at the font, if it meet the requirments as displayed with freetype2: $ ftview 10 /usr/share/fonts/truetype/arial.ttf then hit 'a' to turn off antialiasing and Up/Down to change size. Does the font fulfill your expectation for small sizes as rendered by freetype2? (2) Then, we need to ensure fontconfig gives correct rendering algorithm parameters. Before I do any configuration, I get: $ fc-match -v 'Arial:size=10' | grep 'alias\|hint' antialias: True(w) hintstyle: 3(i)(w) hinting: True(w) autohint: False(w) force_hintstyle: "none"(w) force_autohint: False(w) search_metric_aliases: True(w) $ Three last can be ignored, they just imply real rendering options. For size=10 we get full hinting (hintstyle=3, which is, iirc the only option anyway for BCI), rendering with BCI when the freetype library decides it has usable rendering instructions (autohint=false, it actually means 'do not force autohint') and antialias on. $ fc-match -v 'Arial:size=5' | grep 'alias\|hint\|size' Pattern has 44 elts (size 48) size: 5(f)(s) pixelsize: 5.20833(f)(s) antialias: True(w) hintstyle: 3(i)(w) hinting: True(w) autohint: False(w) [..] $ Lovering the size, fontconfig does not change rendering options, as expected. Now edit ~/.config/fontconfig/fonts.conf: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <alias> <family>sans-serif</family> <prefer> <family>Arial</family> </prefer> </alias> <match target="font"> <test name="font_type"> <string>TT Instructed Font</string> </test> <test name="pixelsize" compare="less_eq"> <double>8.0</double> </test> <edit name="antialias"> <bool>false</bool> </edit> <!-- force autohint should be disabled already --> <edit name="autohint"> <bool>false</bool> </edit> </match> </fontconfig> <alias> is there to make sure Arial is preferred for given user. font_type='TT Instructed Font' is set for all fonts listed in /etc/fonts/conf.d/10-group-tt-hinted-fonts.conf, including Tahoma and Arial. Now: $ fc-match -v Arial:size=10 | grep 'hint\|alias\|size' Pattern has 44 elts (size 48) size: 10(f)(s) pixelsize: 10.4167(f)(s) antialias: True(w) hintstyle: 3(i)(w) hinting: True(w) autohint: False(w) [..] $ $ fc-match -v Arial:size=5 | grep 'hint\|alias\|size' Pattern has 44 elts (size 48) size: 5(f)(s) pixelsize: 5.20833(f)(s) antialias: False(w) hintstyle: 3(i)(w) hinting: True(w) autohint: False(w) [..] $ Antialias is off for the Arial:size=5. hinting need to be true in both cases. autohint is False to allow freetype2 to use font's instructions if there are any; again in both cases. NOTE: you see above the pixelsize is slightly above the requested size. If you want to request size=8, rather use 9.0 inside the fontconfig rule above. Webpage similar to following one should confirm it works: <html> <body> <span style="font-family: Arial; font-size: 5px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 6px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 7px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 8px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 9px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 10px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 11px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 12px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 13px">Pack my box with five dozen liquor jugs.</span><br/> <span style="font-family: Arial; font-size: 14px">Pack my box with five dozen liquor jugs.</span><br/> </body> </html> The jump between non-antialiased and antialiased font is evident or can be proved by xmag utility. Now the system should use this settings. Well. It depends how given application honor fontconfig recommendation how to render a font, of course. You should try another applications, kde, non-kde, etc. If that does not work only for kde applications, for example, then it might be there is some clash between kde and base system fontconfig settings or its interpretion. I needed to increase pixelsize to 14.0 in the fontconfig rule though as 8.0 is simply too low. Arial and even Liberation families are rendered black&white for me on fx. firefox, icewm and pidgin as expected.
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.
Created attachment 712625 [details] my emulation result for the reporter's behavior
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.
https://cgit.kde.org/plasma-desktop.git/commit/kcms/fonts/kxftconfig.cpp?id=88ae0b60b81325b838aae2c48b790b81f810b903 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.
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
JFYI.. (In reply to Marguerite Su from comment #46) > <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> They probably assume/had detected dpi=96: On my system: $ fc-match -v sans:size=8 | grep 'dpi\|size' Pattern has 44 elts (size 48) size: 8(f)(s) pixelsize: 8.33333(f)(s) dpi: 75(f)(s) $ For requested dpi=96: $ fc-match -v sans:size=8:dpi=96 | grep 'dpi\|size' Pattern has 44 elts (size 48) size: 8(f)(s) pixelsize: 10.6667(f)(s) dpi: 96(f)(s) $ Not sure why they add both checks, but the 'size' could perhaps be more appropriate than on 'pixelsize' I offered in comment 45.
@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
(In reply to Marguerite Su from comment #52) > 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 I would oppose that by quoting comment 0: "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." > 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 I had not get the point why embedded bitmaps should be a problem. > 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 I would never mix rendering withoug antialias with subpixel rendering, yes. > But does Tahoma have embededbitmap? Apparently not: > > $ fc-match -v Tahoma:size=8 > embeddedbitmap: False(w) I am not sure fontconfig do some detection trough freetype that font contains embedded bitmaps; the above most likely means 'do not use embedded bitmaps even if rendered font contains them', as our default already for some time. -- I would stick on 42.2 as 13.2 is out of support. Vadim, what says $ fc-match -v sans:size=8 | grep 'family\|hint\|alias' on the 42.2? Assuming you have not touched any other fontconfig settings, but you have just run kde system settings, what says ~/.config/fontconfig/fonts.conf? Is there ~/.fonts.conf? What is there?
Created attachment 712766 [details] 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
(In reply to Petr Gajdos from comment #53) > (In reply to Marguerite Su from comment #52) > > 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 > > I would oppose that by quoting comment 0: "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." > > > 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 > > I had not get the point why embedded bitmaps should be a problem. > > > 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 > > I would never mix rendering withoug antialias with subpixel rendering, yes. > > > But does Tahoma have embededbitmap? Apparently not: > > > > $ fc-match -v Tahoma:size=8 > > embeddedbitmap: False(w) > > I am not sure fontconfig do some detection trough freetype that font > contains embedded bitmaps; the above most likely means 'do not use embedded > bitmaps even if rendered font contains them', as our default already for > some time. > > -- > I would stick on 42.2 as 13.2 is out of support. Vadim, what says > > $ fc-match -v sans:size=8 | grep 'family\|hint\|alias' > > on the 42.2? > > Assuming you have not touched any other fontconfig settings, but you have > just run kde system settings, what says ~/.config/fontconfig/fonts.conf? Is > there ~/.fonts.conf? What is there? $ fc-match -v sans:size=8 | grep 'family\|hint\|alias' Fontconfig warning: "/home/vadymk/.config/fontconfig/fonts.conf", line 37: Having multiple values in <test> isn't supported and may not work as expected Fontconfig warning: "~/.fonts.conf", line 37: Having multiple values in <test> isn't supported and may not work as expected family: "Arial"(s) familylang: "en"(s) antialias: False(w) hintstyle: 3(i)(w) hinting: True(w) autohint: False(w) force_hintstyle: "none"(w) force_autohint: False(w) search_metric_aliases: True(w) $ l ~/.fonts.conf ~/.config/fontconfig/fonts.conf -rw-r--r-- 1 vadymk users 2341 Dec 18 2015 /home/vadymk/.config/fontconfig/fonts.conf lrwxrwxrwx 1 vadymk users 42 Nov 29 2013 /home/vadymk/.fonts.conf -> /home/vadymk/.config/fontconfig/fonts.conf $ cat ~/.config/fontconfig/fonts.conf <?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <match target="font"> <edit mode="assign" name="autohint"> <bool>true</bool> </edit> </match> <match target="font"> <test compare="more" name="weight"> <const>medium</const> </test> <edit mode="assign" name="autohint"> <bool>false</bool> </edit> </match> <match target="font"> <test name="family"> <string>Tahoma</string> <string>Andale Mono</string> <string>Arial</string> <string>Comic Sans MS</string> <string>Georgia</string> <string>Impact</string> <string>Trebuchet MS</string> <string>Verdana</string> <string>Courier New</string> <string>Times New Roman</string> <string>Webdings</string> <string>Albany AMT</string> <string>Thorndale AMT</string> <string>Cumberland AMT</string> <string>Andale Sans</string> <string>Andy MT</string> <string>Bell MT</string> <string>Monotype Sorts</string> </test> <!-- <test name="antialias"> <bool>false</bool> </test> --> <test compare="more_eq" name="size" qual="any"> <double>0</double> </test> <test compare="less_eq" name="size" qual="any"> <double>9</double> </test> <edit name="autohint"> <bool>false</bool> </edit> <edit mode="assign" name="antialias"> <bool>false</bool> </edit> </match> <match target="font"> <edit mode="assign" name="rgba"> <const>rgb</const> </edit> </match> <dir>~/.fonts</dir> <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> </fontconfig>
Indeed, looks like a user setting problem. Here you are: (In reply to Vadim Krevs from comment #55) > <?xml version='1.0'?> > <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> > <fontconfig> > <match target="font"> Turn on autohint for every font. > <edit mode="assign" name="autohint"> > <bool>true</bool> > </edit> > </match> > <match target="font"> > <test compare="more" name="weight"> > <const>medium</const> > </test> > <edit mode="assign" name="autohint"> > <bool>false</bool> > </edit> Do not force autohint, for _every_font_, for weight >= demibold for whatever reason. > </match> > <match target="font"> > <test name="family"> > <string>Tahoma</string> > <string>Andale Mono</string> > <string>Arial</string> > <string>Comic Sans MS</string> > <string>Georgia</string> > <string>Impact</string> > <string>Trebuchet MS</string> > <string>Verdana</string> > <string>Courier New</string> > <string>Times New Roman</string> > <string>Webdings</string> > <string>Albany AMT</string> > <string>Thorndale AMT</string> > <string>Cumberland AMT</string> > <string>Andale Sans</string> > <string>Andy MT</string> > <string>Bell MT</string> > <string>Monotype Sorts</string> > </test> > <!-- > <test name="antialias"> > <bool>false</bool> > </test> > --> > <test compare="more_eq" name="size" qual="any"> > <double>0</double> > </test> > <test compare="less_eq" name="size" qual="any"> > <double>9</double> > </test> > <edit name="autohint"> > <bool>false</bool> > </edit> Do not force autohint for smaller sizes for certain font families. > <edit mode="assign" name="antialias"> > <bool>false</bool> > </edit> > </match> > <match target="font"> > <edit mode="assign" name="rgba"> > <const>rgb</const> > </edit> > </match> > <dir>~/.fonts</dir> > <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> > </fontconfig> All in all, autohint is forced for all fonts with weight <= medium and size, even for Tahoma and others listed in the long match which should not. Also antialias is set to false for certain families/sizes, then it is set to true for all fonts and again set to false for all fonts for certain sizes. Also following warning should not be overlooked: > Fontconfig warning: "/home/vadymk/.config/fontconfig/fonts.conf", line 37: > Having multiple values in <test> isn't supported and may not work as expected It is evident that the file was written by more entities. I guess you have two possibilities after backuping and removing this file: 1. rely on distro setting: we do not support for excluding ranges from antialias though [in fonts-config and/or yast2-fonts, I will consider to add it at least for fonts-config, for yast2-fonts it won't be trivial and even include libfontspecimen changes], so you need to add to your ~/.config/fontsconfig/fonts.conf: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <test name="font_type"> <string>TT Instructed Font</string> </test> <test name="size" compare="less_eq"> <double>8.0</double> </test> <edit name="antialias"> <bool>false</bool> </edit> </match> </fontconfig> Do not use KDE font setting afterwards, without removing the file again. 2. rely on settings written by KDE: After backuping and removing /home/vadymk/.config/fontconfig/fonts.conf, KDE should write a new one.
(In reply to Vadim Krevs from comment #55) > $ fc-match -v sans:size=8 | grep 'family\|hint\|alias' > Fontconfig warning: "/home/vadymk/.config/fontconfig/fonts.conf", line 37: > Having multiple values in <test> isn't supported and may not work as expected > Fontconfig warning: "~/.fonts.conf", line 37: Having multiple values in > <test> isn't supported and may not work as expected > family: "Arial"(s) > familylang: "en"(s) > antialias: False(w) > hintstyle: 3(i)(w) > hinting: True(w) > autohint: False(w) > force_hintstyle: "none"(w) > force_autohint: False(w) > search_metric_aliases: True(w) This looks correctly to me: for size=8, antialias is of, autohinting not forced, hintstyle full, hinting true. But note you have Arial instead of Tahoma standing for sans-serif.
(In reply to Petr Gajdos from comment #57) > This looks correctly to me: for size=8, antialias is of, autohinting not antialias is off
There is still a needinfo request on me, but I am not clear what information to provide.
(In reply to Vadim Krevs from comment #59) > There is still a needinfo request on me, but I am not clear what information > to provide. The needinfo was set on 2017-02-03 by me (comment 53). You have provided the info in comment 55, so you should have tick 'I am providing the requested information for vkrevs@yahoo.com (clears the needinfo request).' just under the comment field, which is self-explaining. However, let us keep this needinfo on you as I suggested in comment 56 two possible solutions for you. Please report back if at least one of them are working for you and if not, please explain what is wrong.
Created attachment 713183 [details] 1. Fonts in a default Leap 42.2 install - no user customizations, no ~/.config/fontsconfig/fonts.conf file
Created attachment 713184 [details] 2. Fonts and settings in a default openSUSE 42.2 install with my "original" fonts.conf
Created attachment 713185 [details] 3. Fonts in a default Leap 42.2 install with your fonts.conf (option 1 from comment 56)
Created attachment 713186 [details] 4. Fonts in a default Leap 42.2 install with KDE-written fonts.conf (option 2 from comment 56)
I've supplied requested info after trying the options from comment 56 on a default leap 42.2 install after creating and logging in as a new user. Neither of the suggested options in comment 56 results in what I used to get in 13.1 (or am getting now) unless I use my own fonts.conf file (without any of your suggested changes) + the steps from comment 2.
(In reply to Vadim Krevs from comment #63) > Created attachment 713185 [details] > 3. Fonts in a default Leap 42.2 install with your fonts.conf (option 1 from > comment 56) Let us please stick only on this case. I assume you have not run KDE's font dialog for that user, please double check that ~/.config/fontconfig/fonts.conf for that user is still the same as you cat in the screen shot. I think you already know, please do not test now on KDE font dialog at all, the result would be misleading. What says $ fc-match -v sans:size=7 | grep 'family\|hint\|alias' $ fc-match -v sans:size=8 | grep 'family\|hint\|alias' $ fc-match -v sans:size=9 | grep 'family\|hint\|alias' on that system for _this_ user?
Created attachment 713221 [details] Outputs of various fc-match commands requested in comment 66
(In reply to Vadim Krevs from comment #67) > Created attachment 713221 [details] > Outputs of various fc-match commands requested in comment 66 Hmm, size pattern entry does not work it seems. Change the settings on the system (comment 63) to: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <test name="font_type"> <string>TT Instructed Font</string> </test> <test name="pixelsize" compare="less_eq"> <double>9.0</double> </test> <edit name="antialias"> <bool>false</bool> </edit> </match> </fontconfig> Please report back how fonts are rendered now.
Created attachment 713505 [details] Outputs of varous fc-match commands and resulting font appearance after fonts.conf from comment 68
Created attachment 713506 [details] How the fonts look under my normal user account with my custom fonts.conf + steps from comment 2 This is what I would like the fonts with whatever necessary customizations in ~/.config/fontconfig/fonts.conf but without having to change anything in /etc/fontconfig or /usr/share/{fontconfig,fonts-config}.
Created attachment 713959 [details] firefox with specimen html displaying fonts black and white for smaller Giving up! As I said, I am able to bring up black and white fonts in gtk applications as demonstrated with the image, I believe this is the state you want to achieve. This is done just with: $ cat ~/.config/fontconfig/fonts.conf <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <alias> <family>sans-serif</family> <prefer> <family>Tahoma</family> </prefer> </alias> <match target="font"> <test name="font_type"> <string>TT Instructed Font</string> </test> <test name="pixelsize" compare="less_eq"> <double>11.0</double> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> </match> </fontconfig> $ on top of 42.2 fontconfig settings plus, of course, instructing gtk applications to actually use smaller sizes. The alias is there to make sure Tahoma is preferred to stand for sans-serif. I can not tell anything about kde applications, though.
(In reply to Vadim Krevs from comment #70) > Created attachment 713506 [details] > How the fonts look under my normal user account with my custom fonts.conf + > steps from comment 2 There is a possible workaround for you: see $ man fonts-conf and search there for FONTCONFIG_FILE
By the way: my recommendation is to use 'Misc Fixed' bitmap font for a terminal ;).
reassigned to Petr. I didn't find any problem related to the system.
Works for me as well.