freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] SVG Rendering Library


From: suzuki toshiya
Subject: Re: [ft-devel] SVG Rendering Library
Date: Fri, 14 Jun 2019 06:34:41 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]