QUOTE(MedO @ Sep 30 2006, 00:05)

Consider this:
Without ClearType, black on white:
::
With ClearType
::
I'm not saying that it's impossible to improve the visual quality on those LC displays with the proper strategies. Your examples may look good in its ASCII art visualisation because the letters R, G and B are similarily darkening the area (same colour) whereas the actual diodes emit light with different wavelengths. So, you still have coloured edges like you mentioned.
QUOTE(MedO @ Sep 30 2006, 00:05)

... It doesn't make much difference with which it stops. ...
I see your point. You silently imposed a restriction on your b/w image: Every line of your example contains 3 consecutive pixel elements (R/G/B) that are switched on. You'll agree with me that
CODE
RGBRGBRGBRGB
RGB BRGBRGB
RGB BRGBRGB
RGB BRGBRGB
RGBR RGBRGB
RGBR RGBRGB
RGBR RGBRGB
RGBRG GBRGB
RGBRG GBRGB
RGBRG GBRGB
RGBRGB BRGB
RGBRGB BRGB
RGBRGB BRGB
RGBRGBRGBRGB
will look ugly (only 2 components set). The line's colour will alternate between magenta, yellow and cyan.
The name for that restriction is: band limitation. This is the way to go. You implicitely used a boxcar filter of length 3. From a DSP point of view there are better filters that even get rid of coloured edges under the assumption that the LC displays' reconstruction filter is a good one (which it usually isn't!). But with other filters there'd still be an improvement. A good implementation
can look good on such a display.
So, to recap: (1) Yes, I'm aware of all this. (2) Many implementations I've seen suck. (3) There's room for improvement. (4) IMHO fixing this my-display-sucks-problem at such an early stage (rasterization stage) is a bad approach because the data in the V-RAM won't be device independant anymore => screen shots look ugly on most other displays.
I happen do own an LC display that blurs each component of a pixel into one square optically. This type of LC displays is very common nowadays and makes ClearType and the like unnecessary.
Cheers!
Sebastian