[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.
>
- Re: [ft-devel] SVG Rendering Library, (continued)
- Message not available
- Re: [ft-devel] SVG Rendering Library, suzuki toshiya, 2019/06/14
- Re: [ft-devel] SVG Rendering Library, Moazin Khatri, 2019/06/14
- Re: [ft-devel] SVG Rendering Library, Moazin Khatri, 2019/06/15
- Re: [ft-devel] SVG Rendering Library, Werner LEMBERG, 2019/06/15
- Re: [ft-devel] SVG Rendering Library, Alexei Podtelezhnikov, 2019/06/15
- Re: [ft-devel] SVG Rendering Library, Moazin Khatri, 2019/06/15
- Re: [ft-devel] SVG Rendering Library, Alexei Podtelezhnikov, 2019/06/15
- Re: [ft-devel] SVG Rendering Library, Alexei Podtelezhnikov, 2019/06/15
- Message not available
- Re: [ft-devel] SVG Rendering Library,
suzuki toshiya <=
- Re: [ft-devel] SVG Rendering Library, Moazin Khatri, 2019/06/15
- Re: [ft-devel] SVG Rendering Library, Werner LEMBERG, 2019/06/16
- Re: [ft-devel] SVG Rendering Library, Moazin Khatri, 2019/06/16