Moazin Khatri wrote: >> BTW, how resvg calculate the bitmap_left properties? > > It doesn't. But we can do it using it. For the sake of this explanation > assume that no scaling is to be performed. We firstly use `resvg' to get a > tight bounding box around the `inked' part. It will return us a rectangle (x, > y, width and height). Once we know this, we can use this `width' and `height' > to create a `cairo surface'. Once that is done, we can use `cairo translate' > to shift the coordinate system so that the origin is at the top-left corner > of this rectangle. This will ensure that we only get a tight box rendered > with no redundant space. Now, we can use the `x' and `y' of this bounding box > to calculate `bitmap_left' and `bitmap_top'. The x can directly tell us > `bitmap_left' and similarly `bitmap_top' won't be much hard to calculate, > just simple arithmetic.
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?. Regards, mpsuzuki _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
