Recently a bug was reported against the midori web browser related to handling of fonts and font properties, which lead me to a lot of digging around and figuring out how browsers handled font processing. Here's a summary of my discoveries for other folks that might be interested:
The bug was reported against webkitgtk (the backend for many web browsers, including midori, epiphany, etc). Basically, fonts in the main webpage browser area were ignoring settings of anti-alias, hinting and hinting style. It would just never change when you changed them in the Xfce or Gnome settings for those items thought the menus/title bar and other items in fact Would change with those settings.
At first I thought this might be a general webkitgtk bug, as it happened in the generic webkitgtk example browser (GTKLauncher). Looking at firefox, I discovered the same issue was there as well, so something deeper was happening. After digging around on the net, I found a few helpful links:
Desktop's set things like anti-alias and hinting prefs in XSettings. Freetype (and under it pango and cairo) use it's own settings to determine these things. Freetype has settings under /etc/fonts/ for system wide settings and looks for per user ones in ~/.fonts.conf or ~/.fonts.conf.d/
So, my understanding of the problem here (and corrections welcome) is that web browsers render things directly using freetype, which doesn't look at or understand XSettings, so changing those things in your desktops prefs has no effect. The menus and title bars and other items are GTK2 and do follow your XSettings just fine. Wekitgtk has also a pango backend that directly uses that and bypasses freetype, but in the past thats caused some issues with some CJK/Unicode fonts, so freetype is used in Fedora.
Short term then, the answer is to just set the prefs the way you want them for your user or globally in freetype and things will look the way you would like them to.
You can also find a copy of my .fonts.conf file here: .fonts.conf (I would have embedded it into this post, but embedding xml bits in html pages gets confusing fast, so just grab the file. ;)
Longer term, I'm not sure what the solution is. I guess that somewhere along the stack of items that web browsers use for this there will need to be XSettings support added, but not sure which part that exactly should be. (freetype? harfbuzz?) I suppose the browsers themselves could add it, but it seems a waste/duplication of effort. Chromium seems to have done just that themselves. Hopefully someone will come up with something that works, as the current setup (having to configure freetype manually) is very much less than ideal, IMHO.comments powered by Disqus