Re: A protuberant Chinese pixel

[David Turner]

Hello Tom,

> 
> Dear FreeType developers,
> 
> FreeType is tremendous! Thanks to all those who created it.
> 
> There is one small point where it looks like the rasterizer could do
> better. A picture and brief description are at this URL:
> 
>     http://www.wenlin.com/freetype.gif
> 
> I don't know the internals of the rasterizer well enough to tell where the
> problem is in the source code, but it seems to involve rounding one way or
> the other from a coordinate exactly half-way between pixel boundaries
> (64*n+32 where n is an integer).
> 
> By the way, the Chinese character outlines in which the protuberant pixel
> is manifested don't come from a TrueType font file (though they could
> have). They are built up one stroke at a time (in standard Chinese
> stroke-order). Each stroke is defined only in terms of its stroke type and
> its endpoints (plus, for some stroke types, one or more turning points).
> The outline of each stroke is constructed on-the-fly by a routine that
> knows, for example, how to add the ornaments at the ends of a Chinese
> horizontal stroke, and fills in a TT_Outline structure that is passed to
> TT_Get_Outline_Bitmap(). Over 12,000 characters are already defined in this
> way.
> 
> Thanks again for FreeType, and thanks in advance to anyone who can fix the
> protuberant pixel (which is really a minor problem).
> 

sorry for this late answer. As you correctly point it, the "problem" occurs
because one outline point lies "exactly" in the middle of a pixel. There's no
ideal way to deal with this kind of situation without performing additional
analysis of the glyph outline (at least in the current rasterizer's design).

I would suggest the following "hack", when rendering monochrome bitmaps:
simple set the least significant bit of each point coordinate to 1. This
will result in a 1/64th of pixel error that will probably be invisible for
hinted glyphs, but prevent "pixel center" cases. As with the code:

   for ( i = 0; i < outline->n_points; i++ )
   {
     outline->points[i].x |= 1;
     outline->points[i].y |= 1;
   }

called just before rendering.. Could you tell me if that solves your problem ?
or distort too much other glyphs ??

Actually, I believe that the anti-aliasing renderer already includes such logic
(but the shift is only applied to points that are effectively on a pixel center,
not other ones). Maybe it'd be a good idea to move this code to the monochrome
renderer too ??

Hope this helps,

- David