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.