Created attachment 470606 [details] Example webkitgtk rendering from Midori Description of problem: I have my font rendering set to RGB sub-pixel anti-aliasing with slight hinting. The webkitgtk component (tested in Midori and Uzbl) insists on using full hinting, see attached screenshots. Version-Release number of selected component (if applicable): freetype-2.4.2-4.fc14.i686 freetype-2.4.2-4.fc14.x86_64 fontconfig-2.8.0-2.fc14.x86_64 fontconfig-2.8.0-2.fc14.i686 webkitgtk-1.3.6-1.fc14.x86_64
Created attachment 470607 [details] Correct sample rendering in Galeon
Does this occur in /usr/libexec/webkitgtk/GtkLauncher ? Thats the best way to tell if this is a webkitgtk issue, or something in one of the packages that uses it. How are you setting things? Gnome with gnome-control-center? kde? xfce?
(In reply to comment #2) > Does this occur in /usr/libexec/webkitgtk/GtkLauncher ? Yes. > How are you setting things? Gnome with gnome-control-center? kde? xfce? Via gnome-control-center (System > Preferences > Appearance).
I can confirm this here. ;( I did some digging around yesterday on it, but didn't find anything conclusive. webkitgtk should handle this, but isn't. ;( It might be a bug in 1.3.x or something wrong in our pangocairo stack. Will keep digging. Thanks for reporting this.
Freetype/cairo seem to be ignoring the XSETTINGS properties when you set them. Instead they look at the freetype /etc/fonts/ stuff. If you make a ~/.fonts.conf and put in it: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <edit mode="assign" name="antialias"><bool>true</bool></edit> <edit name="autohint" mode="assign"><bool>false</bool></edit> <edit name="hinting" mode="assign"><bool>true</bool></edit> <edit name="hintstyle" mode="assign"><int>1</int></edit> <edit name="rgba" mode="assign"><const>bgr</const></edit> </match> </fontconfig> Does it obey those settings for you? I'm not sure what the plan is for getting freetype to read XSETTINGS or otherwise play nice is...
(In reply to comment #5) > Does it obey those settings for you? Yes, it does. Font rendering is now consistent with other applications.
I'm not sure there is any way to fix this in webkit, short of moving to the cairo backend (which doesn't work with some languages correctly). So, options are: 1) Just close this bug and use the freetype config to work around it for now. 2) Try and move this over to freetype to ask them to add XSettings support. 3) close this and wait for webkit upstream to move to another backend. Thoughts?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I'm going to go ahead and close this now. Feel free to reopen if there's further action for me to take.