Sorry for the late reply. What you've pointed out is a serious problem. Sorry for not being able to understand this in your earlier email. :-(
Now after observing these problems what should be our direction of work here? Should we store `un-inked' pixels in the slot->bitmap.buffer? or should we manually remove them and calculate `bitmap_left' and `bitmap_top' ourselves? Should we do it on FreeType side? or expect whatever sits behind the `callback hooks' to do this for us? Also, what about: How do we ensure that at least all the `inked' part is rendered? Because of > the coordinate inversion and the convention that the base line is at y = 0, > most of the glyph won't even make it to the rendered image. To make it a > part of the image we have two options, either manipulate the view box using > some DOM manipulation (or directly changing the document stream), or, using > something like cairo translate. But, in both cases, how much to translate > or how much to shift the viewbox can be determined accurately by knowing > the `bounding box' which would bring us to the same problem. Or we could > guess it. Say if the EM square is 1000. We could use cairo translate so > that everything in the rectangle (in SVG coordinates), (0, 1000) to (1000, > -1000) is rendered. This doesn't guarantee that everything will be rendered > either. I was just rendering a glyph of the character 'j' whose left edge > is at x = -10. So we will need to make this `guess' rectangle even bigger. > And then finding the `inked' part from this huge image is really really > inefficient. >
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
