Description of problem: The font rendering in Rawhide's Qt 4.4.1 is much inferior to that in Fedora 9. The glyphs appear really thin, as if no hinting is being done. Version-Release number of selected component (if applicable): 4.4.1-2 (not sure when the problem started; was noticeable in F10 alpha and still persists) How reproducible: Always Steps to Reproduce: 1. Run qtconfig-qt4 2. Install kdegraphics and run okular Actual results: In both, font rendering looks terrible Expected results: Font rendering should look at least as well as in F9 Additional info:
Also, why does qt4-qtconfig.desktop have "NoDisplay=true" ?
qtconfig, see bug #244879
Seems to be a rawhide-specific problem, qt-4.4.1 on F-9 is fine for me. When/if I make the jump to rawhide on a box of mine, I'll see if I can reproduce this.
There's a new freetype in Rawhide, that might be what causes this.
I can reproduce this with F10-beta.
interesting, in systemsettings -> Appearance -> Fonts, Use Antialiasing "system default" => no antialiasing. "Enabled" => ok and... when I reset back to "system default", things stay ok. freaky
Reassigning to kdebase-workspace (for now, though there's no doubt some qt/kde interaction going on here)
i cannot reproduce this with kde-4.1.1/F9. how can i reproduce this with kde-4.1.1/F9?
(In reply to comment #8) > i cannot reproduce this with kde-4.1.1/F9. how can i reproduce this with > kde-4.1.1/F9? It's Rawhide/F10 specific problem, it is working in F9...
The same problem affects pure Qt applications. KDE's systemsettings is presumably just using/editing Qt's antialiasing settings? In which case, the defaults might for some reason be broken on F10.
Maybe this is due to the new freetype in Rawhide?
(In reply to comment #11) > Maybe this is due to the new freetype in Rawhide? Quick try with Freetype from F9 and it is same (but really quick try) 2.37-1 to 2.3.5-6
it's a bug in /etc/fonts/conf.d/25-ttf-arphic-uming-bitmaps.conf from cjkunifonts-uming that sets antialias=false for pixelsize <= 17. It causes the qt/kde font antialiasing not used initially. Is there any reason why you set antialias=false for pixelsize <= 17? PS: if someone cannot wait for the fix, just remove this package cjkunifonts-uming
Sounds like a configuration problem -- presumably that antialias=false is meant to apply only to uming and not to *all* the fonts? The weird thing is, why does it only affect Qt/KDE?
In main user's point of view, this is what it supposed to be a feature rather than a bug. AFAIK, since cjkunifonts-uming has no hinting data but that is the default font of zh_TW locale, antialias=false for pixelsize <= 17 is somewhat necessary for any user who uses such font with best display quality. People who doesn't need Chinese (Traditional) support should not choose that during installation or later, until at least latest Gnone and KDE support by font antialias rendering on same display. To conclude, IMHO this is not a bug.
IMHO this *is* a bug. Either cjkunifonts-uming is overriding antialias globally, or Qt is parsing the request wrongly and turn off antialiasing for all fonts, and not just the fonts for Chinese (Traditional) support.
A font package must not override global antialiasing settings. Just because a font for traditional Chinese is installed doesn't mean traditional Chinese is the primary language the current user is using, especially on multiuser systems. Several font packages are also installed by default on the live CDs.
This is definitely BUG - it affects another package and makes it totally unusable in default settings. The question is why is it affecting all fonts globally and not only these ones defined in font family test.
(In reply to comment #15) > People who doesn't need Chinese (Traditional) support should not choose that > during installation or later, No that's not acceptable — font packages must not assume any system locale and be installable without side-effects on any system. This point has already been discussed to death last year on the fonts list. (In reply to comment #16) > IMHO this *is* a bug. Either cjkunifonts-uming is overriding antialias > globally, or Qt is parsing the request wrongly and turn off antialiasing for > all fonts, and not just the fonts for Chinese (Traditional) support. I'd even go further, the font has no business changing the settings of any font but itself. If it tries that's a bug in the font package. If it uses the proper checks but QT ignores then that's a QT bug. Looking at the file, the package does try to limit the antialias effect to a set of fonts. So either the check is badly written, and it's a font package bug, or the syntax is ok, and something QT-side makes a mess of it. Behdad should probably be able to tell you if the check is correctly written.
Just to confirm, could you also try testing with cjkunifonts-0.1.20060928 (the version that was also in f9) -- the latest f10 package is a new upstream release.
Created attachment 317907 [details] patch
Created attachment 317908 [details] patch
test patch: http://fedorapeople.org/~cchance/packages/cjkunifonts/cjkunifonts.spec http://fedorapeople.org/~cchance/packages/cjkunifonts/cjkunifonts-0.2.20080216.1-2.patch http://fedorapeople.org/~cchance/packages/cjkunifonts/cjkunifonts-0.2.20080216.1-2.fc10.src.rpm http://fedorapeople.org/~cchance/packages/cjkunifonts/cjkunifonts-uming-0.2.20080216.1-2.fc10.noarch.rpm
Antialiasing is on again.
it fixes the problem. Could you please build it in rawhide? thanks
http://koji.fedoraproject.org/koji/taskinfo?taskID=851180 done
I still don't understand the real cause of the problem. Of course we can move 25-ttf-arphic-uming-bitmaps.conf to /etc/fonts/conf.avail/, though Debian also ships it in conf.d/. Caius, can you please ask upstream about?
It is also a bit hard to test this since current rawhide KDE does not seem to be usable...
Uh, Rawhide KDE is supposed to be usable. It's the stable 4.1.2 release, not some alpha or beta.
(In reply to comment #29) > Uh, Rawhide KDE is supposed to be usable. It's the stable 4.1.2 release, not > some alpha or beta. Yeah one would hope so, but recently when I groupinstall kde-desktop and try it out it just sits there staring at me after startup, I suppose I could file a bug if it is not known... Is it possible to reproduce the problem when running kde applications under gnome?
Something what exactly 25-ttf-arphic-uming-bitmaps.conf does is supposed to apply changes for Chinese fonts only as it's trying to match them. that exactly affected to other fonts right. that may be an idea to get rid of them for a /workaround/. but that looks to me like the real problem is in Qt or fontconfig. otherwise matching tag and testing tag becomes meaningless.
Agreed, reproduced on F10Beta, but pushing this back to Qt since it really looks like a Qt/KDE issue: the changes made to cjkunifonts are just a workaround for this for KDE and the original .conf file clearly should only affect the Chinese font.
Might this be the relevant difference? - <test name="family"> + <test name="family" compare="eq">
/etc/fonts/fonts.dtd defines that "compare" attribute defaults "eq". <!ATTLIST test qual (any|all|first|not_first) "any" name CDATA #REQUIRED target (pattern|font|default) "default" compare (eq|not_eq|less|less_eq|more|more_eq|contains|not_contains) "eq">
It's true that "A font package must not override global antialiasing settings.". Please read the conf I had modified a little bit which enclosed with this reply. And it should replace: "/etc/fonts/conf.d/25-ttf-arphic-uming-bitmaps.conf"
<?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <match target="font" > <test name="family" compare="not_eq"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <edit mode="assign" name="rgba" > <const>none</const> </edit> </match> <match target="font" > <test name="family" compare="not_eq"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <edit mode="assign" name="hinting" > <bool>true</bool> </edit> </match> <match target="font" > <test name="family" compare="not_eq"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <edit mode="assign" name="hintstyle" > <const>hintfull</const> </edit> </match> <match target="font" > <test name="family" compare="not_eq"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <edit mode="assign" name="antialias" > <bool>true</bool> </edit> </match> <match target="font" > <test name="family"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <test compare="more_eq" name="size" qual="any" > <double>8</double> </test> <test compare="less_eq" name="size" qual="any" > <double>12</double> </test> <edit mode="assign" name="antialias" > <bool>false</bool> </edit> </match> <match target="font" > <test name="family"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <test compare="more_eq" name="pixelsize" qual="any" > <double>11</double> </test> <test compare="less_eq" name="pixelsize" qual="any" > <double>17</double> </test> <edit mode="assign" name="antialias" > <bool>false</bool> </edit> </match> </fontconfig>
I'm afraid the part of the above config doesn't do the right thing what you said at least. "not_eq" affects all of fonts except you explicitly described there. it exactly overrides the global settings, regardless of whether or not the result is same. fontconfig config that the font package owns should have its specific config only. otherwise it should be modified in one fontconfig has.
(In reply to comment #37) > I'm afraid the part of the above config doesn't do the right thing what you > said at least. "not_eq" affects all of fonts except you explicitly described > there. it exactly overrides the global settings, regardless of whether or not > the result is same. fontconfig config that the font package owns should have > its specific config only. otherwise it should be modified in one fontconfig > has. Yes... You're right. Because I don't know why without the "not_eq"-s the rest of configs do NOT work... I had mail the config to Caius Carlos CHANCE <cchance>, hope he could get it work.
AFAIK, cjkunifonts shouldn't use any not_eq in its .conf file because this might probably overrides global settings. The global settings are managed as whole but not this package. Even it tested working we aren't appropriate to include. Cheers.
Created attachment 322378 [details] Modified .conf from Baif's. (Reopened for Baif's proposed .conf) I have slightly modified Baif's proposed .conf to using only "eq". This might be able to reduce effects to global settings. Welcome for more discussion.
I found it's not easy make all happy... For QT4/KDE4 with my config in LANG=en_US.UTF8 on my PC, English fonts look fine , Chinese fonts look fine. But if the "not_eq"s have gone, the English fonts would NOT with antialias, but why the GTK/GNOME apps would get the fonts to be with "antialias"? It looks that the config does not effect the GTK/GNOME apps.
Do you mean you think it is a Pango bug?
I'm not really understand the fontconfig with Pango and Qt. But I think the default settings for Qt/KDE on Fedora is not as good as for GTK/GNOME. And I really understand international for Qt is not as good as GTK. :) BTW: Why fonts for Qt/KDE with LANG=zh_CN.UTF8 had been change, which config file will make this happen? Thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
rdieter, kevin_kofler upstream, wontfix or cantfix?
shrug, upstream to trolltech would be the only sane way forward, imo. That would require someone who's experiencing this, and reproduce with a minimal test case. Any takers?
Caius, could you do that, please?
Created attachment 330210 [details] Screenshot with rawhide and qt-4.4.3-13.fc11.i386
For KDE-LiveCD, the following .fonts.conf works! Caius, can you test it without the first part of "not_eq"? <match target="font" > <test name="family" compare="not_eq"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <edit mode="assign" name="antialias" > <bool>true</bool> </edit> </match> <match target="font" > <test name="family"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <test compare="more_eq" name="size" qual="any" > <double>8</double> </test> <test compare="less_eq" name="size" qual="any" > <double>12</double> </test> <edit mode="assign" name="antialias" > <bool>false</bool> </edit> </match> <match target="font" > <test name="family"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <test compare="more_eq" name="pixelsize" qual="any" > <double>11</double> </test> <test compare="less_eq" name="pixelsize" qual="any" > <double>17</double> </test> <edit mode="assign" name="antialias" > <bool>false</bool> </edit> </match> </fontconfig>
Replace 25-ttf-arphic-uming-bitmaps.conf this conf, check if the Chinese are not antialias within the range. BTW: qtconfig-qt4 will ignore the fontconfig ?
(In reply to comment #50) > Replace 25-ttf-arphic-uming-bitmaps.conf this conf, check if the Chinese are > not antialias within the range. Could you kindly have a test? Thanks. BTW, would the first <match> too over-ruled to force all non-uming have antialias enabled? ===== The two <match> are somehow overlapped: 11 >= pixelsize <= 17 OR 8 >= pixelsize <= 12 becomes 8 >= pixelsize <- 17 which font sizes 8 - 17 would have antialias disabled?
This makes when uming pixelsize < 17, has antialias and hinting off. Please kindly test: ===== <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <test name="family"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <edit name="autohint"><bool>false</bool></edit> </match> <match target="font"> <test name="family"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <test name="pixelsize" compare="more_eq"><int>17</int></test> <edit name="antialias" mode="assign"><bool>true</bool></edit> <edit name="hinting" mode="assign"><bool>true</bool></edit> </match> <match target="font"> <test name="family"> <string>AR PL UMing CN</string> <string>AR PL UMing HK</string> <string>AR PL UMing TW</string> <string>AR PL UMing TW MBE</string> </test> <test name="pixelsize" compare="less"><int>17</int></test> <edit name="antialias" mode="assign"><bool>false</bool></edit> <edit name="hinting" mode="assign"><bool>false</bool></edit> </match> </fontconfig>
Created attachment 330696 [details] Screen with .conf in last comment.
>1.Could you kindly have a test? Thanks. :( Sorry, since I got a new job, I have no additional resources... My personal laptop is running F8 with KDE 3.5. I only have a livecd for testing. >2.BTW, would the first <match> too over-ruled to force all non-uming have >antialias enabled? Yup. It seems that, this 25-ttfxxx-bitmap.conf disabled the antialias for other fonts in my f10 kde livecd. Where is this bug originated... >3. The two <match> are somehow overlapped I'm not sure of that. Since the targets are "size", and "pixelsize". And The first "not_eq" match should be there to enabled antialias on F10 KDE LiveCD. How about yours?
(In reply to comment #54) > :( Sorry, since I got a new job, I have no additional resources... My personal > laptop is running F8 with KDE 3.5. I only have a livecd for testing. That' alright. >2.BTW, would the first <match> too over-ruled to force all non-uming have > >antialias enabled? > Yup. It seems that, this 25-ttfxxx-bitmap.conf disabled the antialias for other > fonts in my f10 kde livecd. Where is this bug originated... The .conf in comment #52 should not affect global antialias configuration. > >3. The two <match> are somehow overlapped > I'm not sure of that. Since the targets are "size", and "pixelsize". Hmm I should get back and check what is the differences. > And The first "not_eq" match should be there to enabled antialias on F10 KDE > LiveCD. I personally think whether antialias is enabled or not globally, should not be controlled by cjkuni-fonts.
Still looking for extra testing.
Maybe, the reason for disabling antialias for other fonts is: Uming has alias as Serif San fonts in the other conf file. And KDE/Qt apps vs GNOME/GTK apps have different fonts display on Fedora.
Wait for feedback from rawhide users: http://koji.fedoraproject.org/koji/buildinfo?buildID=81266
How to get update to rawhide from Fedora Alpha KDE Live CD?
(In reply to comment #59) > How to get update to rawhide from Fedora Alpha KDE Live CD? Enable rawhide repo in /etc/yum.repos.d/ ?
Could you test it in KDE? Things do not work out for me.
Could you tell me what is your testing env and procedures please?
@Baif: so this is ok now?
I removed the bitmap fontconfig in cjkuni-fonts-0.2.20080216.1-30.fc13.