Re: [ft-devel] SVG Rendering Library

[suzuki toshiya]

>If all of them have such, I would discuss such API is acceptable for SVG 
>Native Viewer.

I meant, I would discuss whether such API is acceptable for SVG Native Viewer.

Regards,
mpsuzuki 

On 2019/06/14 19:05, suzuki toshiya wrote:
> 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
>>
> 
> 
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nongnu.org%2Fmailman%2Flistinfo%2Ffreetype-devel&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C2efe3b7c5e034097332f08d6f0afee21%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C636961035756964757&sdata=BxfPD1Opyt5uWRZkrcT6qEH3pY5yzTIC6gcfUtvPwxM%3D&reserved=0
>