Re: [ft] Determining pixel dimensions for bitmap

[Werner LEMBERG]

>> 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.
> 
> Ok. But what's your exact definition of "rounding up"? Should it be rounded
> up whenever the fractional value is != 0?

Yes.  Normally, as soon as you exceed an integer, there will be some
`ink' on the next pixel.

> The problem for me is that I'm not using the glyph API but the
> FT_Stroker and FT_Outline APIs directly. Of course I can detect an
> empty row or column on my own, but if I want to have a bitmap that
> doesn't contain any empty rows or columns, I'm forced to copy the
> pixels to another bitmap because the current APIs don't give me the
> chance to allocate a bitmap of the *exact* dimensions before drawing
> to it.

Just to be sure: You have an outline, you apply FT_Stroker stuff, then
you want to get the exact dimensions of the outline for a given
resolution, right?

My guess is that `FT_Outline_Get_BBox' + rounding as described above
should deliver exact results in almost all cases.  Exceptions are
outlines that have very thin, needle-like spikes that don't have
enough surface (i.e., less than 1/256th of a pixel square) to give ink
to a pixel.  However, as soon as you use the stroker, such needles
become thicker anyways...


    Werner