Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

Dear Moazin,

On 2019/06/14 17:27, Moazin Khatri wrote:
> For the sake of this explanation please assume that we are only talking about 
> the SVG documents which only contain one glyph and the whole document is 
> supposed to be rendered.

OK!

> [...] I want to know how they are required for SVG-OT.
> 
> Imagine we are using FreeType to render an apostrophe ` ' ` using a TTF font 
> like `lucida'. What FreeType would do in this case is return a very small 
> bitmap in `slot->bitmap.buffer' containing very little pixel data and it will 
> also give us `bitmap_left' and `bitmap_top' which will tell us how to 
> position the newly returned pixel data in a drawing context. In case of an 
> apostrophe it is supposed to be pulled up. In case of a comma ` , ` it will 
> be pulled down. I THINK this information is given by `bitmap_left' and 
> `bitmap_top'. Correct me please if I have got this concept wrong. Assuming I 
> have got this correct, I can reach the conclusion that FreeType renders a 
> glyph in the tightest bounding box possible (with no redundant white space) 
> and gives the positioning information using `bitmap_left' and `bitmap_top'.

Thank you for detailed explanation. My understanding is exactly same.

> If the above conclusion is correct, let me now discuss how SVG glyphs are 
> placed. I am attaching the a rendered SVG document for the apostrophe 
> character. In this image, the bottom left corner is (0, 0) of the SVG 
> coordinate system, bottom right corner is (1000, 0), and top left is (0, 
> -1000). According to the specs the base line is at y = 0. The information 
> about where to place this glyph is already encapsulated in the document.

OK.

> If we want to make FreeType behave with SVG glyphs in exactly the same way 
> that it behaves with TTF scalable glyphs, we must render only the tightest 
> bounding box around the glyph (with no redundant white space), and provide 
> `bitmap_left' and `bitmap_top' separately to our clients (the program that is 
> using FreeType for rendering SVG glyphs). To do this, firstly we need a glyph 
> rendered in the tightest box.

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?

> This is possible only if you know the bounding box in SVG coordinates, 
> (`resvg` just added a function that tells this) and then you can do `cairo` 
> translation transformation to exactly get the useful pixel data and nothing 
> else. With the bounding box information (its x, y, width and height) you can 
> also calculate the `bitmap_left' and `bitmap_top' needed.

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.
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.

BTW, how resvg calculate the bitmap_left properties?

Regards,
mpsuzuki