Sorry for lated response. Werner LEMBERG wrote: >> 1. Get the pixel data of the whole SVG doc [...] >> 2. Get the bounding box of the whole doc (or the particular node) in >> SVG coordinates. [...]
> OK. Toshiya-san and/or Moazin, what about svgnative? The SVG document object in SVG Native Viewer have the APIs to retrieve the width and height, SVGDocument::Width() and SVGDocument::Height() https://github.com/adobe/svg-native-viewer/blob/master/svgnative/src/SVGDocument.cpp See line 75 and 77, they are taken from the viewbox. But no API for bitmap_left and bitmap_top. I want to know how they are required for SVG-OT. For conventional sbit font, recording the bitmap_left, bitmap_top as numerical parameters is good idea to the non-inked pixels around the glyph bitmap (in EBDT spec, the glyph bitmaps are stored with their metrics data). The font rasterizer should reflect the bearing information to obtain the correctly rasterized bitmap. According to the spec saying "the SVG origin (0,0) is aligned with the origin in the TrueType/CFF design grid; and y = 0 is the default horizontal baseline used for text layout" and "As with CFF glyphs, no explicit glyph bounding boxes are recorded", I guess, the rasterized image is expected to be placed as if bearingX bearingY are zero. Yet I've not experienced by myself, using bitmap_left = 0 && bitmap_top = 0 cause some inappropriate result? About the possibility of the calculation of bounding box (spec says "The ink bounding box of the rendered SVG glyph should be used if a bounding box is desired; this box may be different for animated versus static renderings of the glyph."), I'm not so much positive to do it within SVG Native Viewer. Let's think about a case: we set 1024 x 1024 image, and put on a circle with radius 128, at the center of the square image, and use it to clip a small circle from the square image. After the rasterization, there would be 448 white space at the left side of the circle, it looks like as if bearingX is 448. But it would not be so easy for the SVG renderer to calculate this length mathematically. If I'm forced to do that, I would suggest to find inked pixel after the rasterization. Regards, mpsuzuki _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
