>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 > [email protected] > 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 > _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
