> Ummm. At present, I cannot find anything corresponding to > cairo_recording_surface_ink_extents(), in Qt and Skia. I remember SkPath > has > something similar for a path object, but I cannot find in QPainter or > SkCanvas. > So, if there is serious requirement to calculate bitmap_left and > bitmap_top and > remove the surrounding un-inked pixels from the image in the buffer, such > pixel > data manipulation is recommended to be done in the side of FT X-(. Nothing > to > say, expanded pixel data must be stored in the side of FT, so what we > should > consider is: a) scanning the pixel data is too heavy work for the font > rasterizer? b) cropping the inked part from a rasterized data and copy to > another heap is too heavy work for the font rasterizer?. >
Hmm yea. But still, one problem remains. 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. `Resvg' works with two graphic backends, `cairo' and `qt', so it would be interesting to look at how they calculate the bounding box. From a quick look, it looks like they use some recursive mechanism to calculate the bounding box of each element and then expanding it with every iteration until the final bounding box is calculated. I am wondering if the devs of `svgnative' can implement something like this?
_______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
