Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

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