On Tue, Nov 13, 2001 at 09:10:57PM -0800, Keith Packard wrote: > > Around 23 o'clock on Nov 13, yao zhang wrote: > > > For those thinner stroke fonts, the anti-aliased text can not reach its > > fullest darkness and appears so light that they are almost > > indistinguishable from the white background. Now anti-aliased text is not > > good to the eye anymore. > > I wonder how much this has to do with our alpha composition working in > linear value space instead of linear intensity space. One way to test > this is to take these same fonts and use them in opposite colors; white > text on a black background. If you see them as overly bright in this > context, then it's not incorrectly computed alpha values, it's the lack of > monitor gamma correction in the compositing computation. > > Another test is to use xgamma (on X servers which support it) and adjust > the gamma value until the density of white on black text appears the same > as black on white text. > > It may be that we'll want to revisit our simple linear computation in > favor of adding a gamma correction (table/value) to the extension.
This is not at all a monitor gamma issue. Doing antialiasing in a luminance-linear space makes black-on-white text _lighter_ than doing it in a perceptual space. The LUT proposed here makes it darker. For very thin white text on a black background, you _do_ want to make it lighter. In this case, rendering in a luminance-linear space beefs up the stroke weights, which makes the rendering more pleasing. Note that in both cases, the LUT post-processing goes in the direction of making stroke widths heavier. The simple fact of the matter is that aa rendering sucks for stroke widths of less than one pixel. I've been studying screen font rendering pretty intensely recently (no pun intended, of course), and do not yet have clear recommendations (npi again) about how to do a good job. I can give a few datapoints, however, for newer renderers. Mac OS X does direct aa rendering (in other words, no quantization to, say, 1/4 pixel), no hinting, and no gamma adjustment. Generally, the results are good, primarily due to factors other than the font rendering technology itself. For one, the entire desktop is rendered quite softly, so the relative lack of contrast for the fonts is not so noticeable. For another, Apple has chosen fonts and weights that work well antialiased. Sans serif fonts, with relatively uniform stroke weights, generally render better than serif fonts. The primary UI font, Lucida Grande at (I believe) 13.6 pixels, has a lowercase "l" width of about 1.17 pixels. This is enough to give reasonable contrast. As an aside, Mac OS X generally ignores instructions (hints). The exception is when you explicitly request non-aa rendering. In this case, hint processing is quite buggy. The evil PMingLiU.ttf font is a good test case for this. Adobe Acrobat 5 is perhaps even more interesting, as it contains some genuinely new font rendering technology. It applies a different hinting processor for aa rendering than non-aa. This hint processor subtly shifts strokes so that they render with high contrast, but does not quantize stroke weight. Because the hinting is so much less heavyhanded than typical TT instructions, letterforms look good, but the contrast is better than the completely unhinted case. I'll post another notice here when I've gathered all my samples and have screenshots. Raph _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
