On Tue, 17 Nov 2009 00:57:44 +0100, micu <micuin...@gmx.de> wrote: > It can have the following values: > > lcdnone lcdfilter 0 > lcddefault lcdfilter 1 > lcdlight lcdfilter 2 > lcdlegacy lcdfilter 3 > > I guess, this is it---isn't it?
Yes, that looks like it. Are these supported in upstream fontconfig? If so, then the bug of interest would be an upstream feature request to support these values within cairo. (Me, I still think the names of those filters are terrible, but if I don't have to provide those as, for example, an enum in the cairo API, then I probably don't have a veto on that. If we *do* want new cairo API to capture these settings, then I'll definitely want different names.) > Yes, I get that---by the way: Is there ANY display out there that has bgr, > vrgb, or vbgr? Sure. Lots of LCD monitors can be rotated 90 degrees between "landscape" and "portrait" orientations, (both big monitors on a desk, and then of course all these little phones that people carry around). > But how does the filter know, where the font sits on the display. Meaning: > whether the upper left of the "A" it has to render is under a red pixel or a > blue pixel, and so on? The question above mixes up some concepts. When you've got an "A" to render, the first thing to do is to construct a path that represents the desired shape of the "A". So you ask freetype for that and now you've got a bunch of coordinates describing the outline. The next step is "rasterization" which takes those outline coordinates and constructs a mask a 3 times the horizontal resolution of your output device. (So if your final 'A' will take 5x8 pixels, this mask has 15x8 values in it.) This rasterization step is not at all aware about colors. It's simply the exact same algorithm that would be used to create the 5x8 opacity values if you were doing grayscale rendering. So each of the final 15x8 values represents "coverage"---a value indicating how much of the sub-pixel is covered by the shape, (0 for no coverage up to 255 for fully covered). The final step, then, is the filter that takes as input these 15x8 values and produces a new set of 15x8 values. This step is color-aware and tweaks the coverage values to make the color fringes less noticeable. This is all about tradeoffs since you're given a value representing coverage, but you'll be handing it off to a device which will use it to represent color. Does that make a bit more sense? -Carl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
