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 <[email protected]> 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. _______________________________________________ Freetype mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype
