On Fri, 13 Nov 2009 22:33:13 +0100, micu <[email protected]> wrote: > If I say, I disable subpixelhinting, that means > > <match target="font" > > > <edit mode="assign" name="rgba" > > > <const>rgb</const> > > </edit> > > </match> > is changed to > > <match target="font" > > > <edit mode="assign" name="rgba" > > > <const>none</const> > > </edit> > > </match>
Ah, thank you. That's much more clear. Let's call this setting "sub-pixel rendering. It specifies whether the font rendering should take advantage of the spatial relationship of the individual red, green, and blue sub-pixels to squeeze out extra spatial relationships. "Hinting" is actually an entirely separate issue, (though good hinting is generally required before sub-pixel rendering will look good). You can tell if you're getting sub-pixel rendering by looking at the pixels on the edges of your rendered glyphs. It they are all shades of gray then sub-pixel rendering is not happening, but if they are many different colors, then sub-pixel rendering is happening. > If I say, I set the hinting style to > > a) off / none > b) slight > c) medium > d) full, > > it means I change > > <const>hintmedium</const> > to > a) <const>hintnone</const> > b) <const>hintslight</const> > c) <const>hintmedium</const> > d) <const>hintfull</const> Yes, this is "hinting style". And for this, I can see code very clearly in cairo that reads these values from fontconfig and sets corresonding options within freetype. See here for example: http://cgit.freedesktop.org/cairo/tree/src/cairo-ft-font.c?id=26e9f149063b9e1fdb54fc54fccbefdf04a68190#n1387 So I would be very surprised if this wasn't working. > Finally, I choose "native" or "autohinter" font rendering by executing "dpkg- > reconfigure" fontconfig-config and selecting "native" or "autohinter", > respectivly. I'm not familiar with this setting at all, but from looking at cairo's code, it looks like dpkg-reconfigure is probably just changing a fontconfig setting (such as in /etc/fonts/conf.d), and this is likely what cairo is doing in response: http://cgit.freedesktop.org/cairo/tree/src/cairo-ft-font.c?id=26e9f149063b9e1fdb54fc54fccbefdf04a68190#n1427 So, so far it looks like cairo is at reading thee settings correctly from fontconfig and pass them on correctly to freetype, (or at least trying to). > I would expect that---if I enable subpixel hinting in .fonts.conf---it should > also affect GTK apps, but it does only affect Qt apps. Why do I think so? > > See the menu entries of Konqueror and Iceweasel in > > withoutsubpixelhinting(hintmedium,nativ).png > > The font rendering seems to be very similar between Konqueror and Iceweasel. > > Now see > > withsubpixelhinting(hintmedium,nativ).png > > The font rendering of Konqueror changes (it gets smoother), but the rendering > of Iceweasel seems to stay the same as without subpixelhinting. Thank you very much for stating exactly what you see as the problem. I can finally look at these images and see the differences that you find objectionable. But, I think you'll need to look a bit closer, because the rendering of the text in iceweasel is certainly not the same in the two images. If you look closely (for example by running xmag to magnify the images), you'll see that without sub-pixel rendering both iceweasel and konqueror render the glyphs in grayscale. And yes, in this case the rendering of the glyphs is virtually identical in the two applications. Then when you enable sub-pixel rendering, both applications start using various colors on the edges of the glyphs. So it's not the case that anything is simply ignoring your configuration. But yes, the actual sub-pixel rendered results are different between the two applications. The easiest place to see this is in the vertical stems. When you have sub-pixel rendering turned on, iceweasel is rendering vertical stems as a precise, single column of black pixels. Meanwhile konqueror renders the vertical stem smeared out very slighty into neighboring columns of pixels. The difference is as easy to explain as the fact that there is different software involved in both cases. The process of sub-pixel rendering involves two basic steps: 1. Rasterizing the glyphs at 3x the horizontal resolution. 2. Filtering that result to reduce the appearance of "color fringes", (objectionably noticeable colors on the edges of glyphs visible without any magnification). I don't know for sure what konqueror is doing, but I know the history of cairo's code, so I can talk about that. Cairo uses freetype to rasterize the glyphs and then uses its own code for the sub-pixel filtering. This filtering code was originally developed by Keith Packard as part of the Xft library. Later, the freetype library acquired its own (different) code for sub-pixel filtering. And it, in fact, has multiple implementations of the filtering, than can be selected by the user. Cairo does not currently use freetype to do the filtering. I'm guessing that konqueror does, (but that's only a guess---Qt could be doing its own filtering as well). There has been some talk on the cairo list about using freetype's sub-pixel filtering, but never any consensus on what change to make. Here are some of the issues: 1. Different people disagree as to which result actually looks better. I happen to be in the camp that really does prefer vertical stems to be rendered as sharp as possible, (without blurring into neighboring columns of pixels). 2. Nobody has proposed good names for what the options would be here. Font configuration on Linux is already a very messy place. For example, the 4 different hint styles you referred to earlier actually map to fewer than 4 different behaviors. We're giving the user more options than even control things. So some people have asked that cairo have yet another option to control the sub-pixel filtering. The possibilities could include at least: cairo's current algorithm, one or more of the various freetype algorithms. The freetype algorithms are currently named after low-level details of the implementation (FIR3, FIR5, etc.) which would obviously be totally meaningless to an end-user. I've personally been unwilling to add an option to cairo to control sub-pixel filter until someone can propose names for the options that actually map to differences the end user would like to effect. > Ok. If I do run gnome-appearance-properties and set my desired options, it > does affect some apps like GIMP, but NOT Iceweasel. Correct me if I am wrong, > but shouldn't GTK apps work properly without gnome-settings-deamon > installed? Sorry for getting you distracted. The gnome-appearance-properties thing wasn't necessary at all. > > Your message says that gtk/gnome applications render the "same" whether > > you disable subpixel hinting or enable subpixel hinting. > > Yes, at least thats is my impression. As described above, your screenshots show that gtk/gnome applications (including iceweasel) *are* in fact responding to the "rgba" setting to determine whether subpixel rendering should be performed. They're just implementing it differently than your KDE applications, as described above. > > Meanwhile, "beautiful" and "perfect" are not helpful descriptions of > > behavior. > > I am very sorry, I had a hard time finding the right words for filing this > bug > report, as this whole font rendering issue is more a matter of "feeling" and > cannot be expressed quantitativly :). I hope I did better this time. It is hard, yes. And your description this time was much better. You were able to tell me that you like the change in the appearance of konqueror's text when you enable subpixel rendering, and that you don't like the (more subtle) change in the appearance of iceweasel's text when you enable the same setting. With that, it was much easier for me to actually look and see what's happening here. > I am sorry, I reported it to cairo, I didn't know where else to put it. And I > guess, it CAN be a cairo issue, because there was this cairo patch that is > suppossed to solve a issue that seems to be similar to mine, and these arch > linux guys also talk about cairo referring to a similar GTK app rendering > behavior. (See the two links in my original bug report). You certainly don't need to apologize. And you're likely right that if you want a change here, the change will porbably have to happen in cairo. The open upstream cairo bug for this issue is here: http://bugs.freedesktop.org/show_bug.cgi?id=10301 In comment #67 there I suggested that the API discussion needed to take place on the mailing list, which happened in this thread here: http://lists.cairographics.org/archives/cairo/2009-January/016437.html and then continued into February here: http://lists.cairographics.org/archives/cairo/2009-February/016461.html I hope that helps. -Carl -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
