Re: [ft] Determining pixel dimensions for bitmap

[Alexei Podtelezhnikov]

Earlier you said:

> > width = bbox.xMax - bbox.xMin;
> > height = bbox.yMax - bbox.yMin;
> >
> > pixelwidth = width >> 6;
> > pixelheight = height >> 6;
> >
> > if((width & 0x3f) > 31) pixelwidth++;
> > if((height & 0x3f) > 31) pixelheight++;

Actually, xMin and and yMin have to be rounded down, and xMax and yMax
have to rounded up individually *BEFORE* you calculate the pixelwidth
and pixelheight.

On Mon, Nov 3, 2014 at 2:24 AM, Werner LEMBERG <address@hidden> wrote:
>
>>>it seems most of my calculations for freetype are based on ceil() so
>>>yes... if any fraction round up...
>>
>> ...but this can lead to empty rows/columns.
>
> Well, yes.  It's the job of the rendering algorithm to find out the
> coverage of a pixel at the outline border.  So it indeed might happen
> that a coordinate of an extremum slightly exceeds an integer value,
> and the associated pixel coverage is still zero.

Theoretically, yes if the coverage is less than 1/256 of pixel area.
So this is just rounding issue while we use 256 shades of gray. The
other potential issue is that Freetype actually goes with CBox of
control points but as we know the extreme points are usually `on'.

What's the big deal about an empty row or column? When rendering text
we suggest using lsb_delta and rsb_delta to properly place the
rendered glyphs. Werner, is it only for hinted text? We might expand
the usage for the bitmap pixel rounding if is not used in this context
yet.