[Vm-dev] Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

Juan Vuletich juan at jvuletich.org
Thu May 21 02:05:28 UTC 2009


Hi Folks,

Andrew Tween wrote:
> ...
>  
> It is possible to replicate this effect by storing these 'coloured' 
> glyphs, and rendering them using the existing bitBlt rules, and, for 
> black text on a white background, it will give the correct result.
>  
> But, when these same glyphs are rendered to a black background (i.e. 
> black text on a black background), the colour fringes in the resulting 
> output are still visible. This is of course wrong; black text on a 
> black background should result in a completely black result with no 
> glyphs visible at all.
>  
> It would be possible to use the existing bitBlt modes if the 
> background colour was known in advance. In this case glyphs could be 
> created and cached for each foreground/background combination.
> But, this is usually not the case. The background might be a gradiant 
> , or an image, or some other pattern.
>  
> Furthermore, the text colour may not be black - it can be any colour 
> with any level of translucency.
>  
> I believe that the existing bitBlt rules are insufficient to cover all 
> these circumstances, but I am happy to be proved wrong :)

Well, not all these circumstances, but all those with black text. You 
can see in the latest Cuis that rgbMul is enough for correct subpixel 
rendering of black text over any background. And yes, black on black 
shows all black. In fact, rgbMul is the same formula than rule 41 if 
text color is black (0;0;0).

In Cuis I disable subpixel rendering for colored text. I found that for 
colored text, the difference between doing or not subpixel rendering is 
much less visible.

As I write this, I realize that it could be possible to do subpixel 
rendering with smarter colormaps... I guess I'll play a bit with this idea.

BTW, I tried to use rule 41 in Cuis, but as r, g and b are alpha values 
(0 meaning transparent, 255 meaning opaque), the glyph form can not be 
the same as used for other rules (such as rgbMul and Paint). As I have a 
single glyph for each char/font/size, and I need to use different rules 
and colormaps to adapt to various display depths and text colors, I 
could not use rule 41. It would have made more sense to me to store 
transparency values (0 meaning opaque, 255 meaning transparent).

Finally, I wonder, what do you guys use for text rendering for your 
Squeak programming? Are you happy with just full pixel AA on LCD screens?

Cheers,
Juan Vuletich


More information about the Vm-dev mailing list