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: Sun, 16 Jun 2019 03:38:24 +0900
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

Dear Moazin, Werner and Alex,

Sorry, I would be slow for a week because of my attendance to a foreign 
meeting, please allow me to be unable to respond your questions timely.

As Werner questioned, I'm wondering what kind of the utilization of the 
(precise) boundingbox of SVG glyph is assumed by "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 should ask in 
OpenType mailing list. In above part of the spec, it is written as "Glyph 
advance widths or heights are the same for SVG glyphs as for TrueType/CFF 
glyphs, though there may be small differences in glyph ink bounding boxes. 
Because advances are the same, switching between SVG and non-SVG rendering 
should not require re-layout of lines unless the line layout depends on 
bounding boxes.", it sounds as if the fonts should be designed as the metric 
values from TrueType or CFF glyphs could be used as if they are same for SVG 
glyphs.

I think there would be 3 positions about this issue. Yet I've not decided my 
own position.

A: Don't care at all about the precise boundingbox for inked pixels, just use 
viewbox values. Leave it to the responsibilities of font producers.
In sbix font, it is possible to make a font which has a PNG including wide 
un-inked surrounding pixels and narrow bitmap_left, bitmap_top. I think 
FreeType do not remove the un-inked surrounding pixels, nor recalculate 
bitmap_left & bitmap_top. I don't know whether such fonts can cause some 
problem, but I don't think FT has a hook to avoid it.

B: Calculate the boundingbox without real drawing and without the 
considerations on clipping and transparent pixels in raster images. Leave it 
to... (ditto)
Hearing Alexei's comment, and looking at the behaviour of 
cairo_recording_surface_ink_extents(), some people may think "calculated 
boundingbox is sufficiently useful even if does not reflect the clipping or 
transparent pixels in raster images, maybe the majority of SVG-OT would not use 
such complicated SVG".

C: Measure an "approximate" boundingbox by small-scaled rasterization.
If it is too slow to scan 1000 x 1000 pixels to measure the precise boundingbox 
of the inked ARGB pixels, it would be acceptable for 128 x 128 or 64 x 64 
bi-level pixels?

Regards,
mpsuzuki

P.S.
Sorry Moazin, I understand yet I've not responded the question raised by you, I 
need more time to consider them...

On 2019/06/16 2:17, Alexei Podtelezhnikov wrote:
> 
> I also don’t get it. What’s the problem? FreeType always does it from 
> outlines. It allocates the bitmap memory. It happens to be tight in most 
> cases because there is usually on-points at the extreme. Otherwise it is a 
> bit larger.
> 
> Well, the same goes for most SVG rendering libraries. They provide functions 
> that can do this. The bounding box will be tight unless "clipping" has been 
> used in which case it will be bigger. That's the problem.
> 
> Also the render module interface has a function pointer that should return 
> the bounding box from outside.
> 




reply via email to

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