Mmm, please let me ask a question. It is true that there are many un-inked pixel around apostrophe glyph. But, do we need to exclude surrounding un-inkeds pixel when we put some SVG glyph into slot->bitmap.buffer? If we pass an image with surrounding un-inked pixels to slot->bitmap.buffer, what kind of the troubles would happen?
I am not really sure if there will be troubles and if so, of what kind.
I didn't see FreeType doing this sort of a thing (putting in un-inked pixels to correct positioning) before with any other types of fonts and thus assumed that it shouldn't be done that way. If there are situations where this is already done then it is fine doing it this way I think. Let me know if there are situations like that.
I understand. Because you think as we should remove the surrounding un-inked pixels before passing a glyph image to slot->bitmap.buffer, you want to obtain bitmap_left and bitmap_top, to pickup the inked part of the rasterized result.
Exactly! :)
Maybe your concern is "even if having surrounding un-inked pixel does not cause serious problem, it means that the client would receive different metrics information for same glyph ID, depending whether the glyph is TrueType or SVG". Yes, it might be slightly confusing... I should think more about it.
Yea, we should think more about this. Even if there are no problems with doing it this way, the demands we have from the SVG rendering library stay the same. We still need the bounding box for ensuring that the all of the inked pixels get rendered.
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.