Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

Oh, I should add a few more.

> I'll look into how CFF glyphs behave, I am unaware of that at the moment. But 
> if CFF glyphs also keep the positioning information in `slot->bitmap.buffer' 
> by putting in empty pixels, then that is a possibility too.

It's not so hard for CFF or TrueType rasterizers to calculate bitmap_left and 
bitmap_top, because these rasterizers operate with the pixel data to be filled, 
directly.

But I'm questionable whether we can expect all scalable graphic frameworks 
should have such feature. If we are focused to the path objects, it would be 
easy, but considering about the clipping feature, I feel it's complicated works.

Just I've checked Cairo, and I found cairo_recording_surface_ink_extents() to 
get x0, y0, width, height of boundingbox of inked area. It would be definitely 
useful. I would check Skia, CoreGraphics and Qt. If all of them have such, I 
would discuss such API is acceptable for SVG Native Viewer.

Regards,
mpsuzuki

On 2019/06/14 18:44, suzuki toshiya wrote:
> 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
>