[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 14:00:24 +0000 |
Dear Moazin,
Please browse the attached SVG: which paints a big blue square (1024 x 1024),
and clip small circle at the center of it (r=64). How do you evaluate the
bitmap_left and bitmap_top? bitmap_left is 512 - 64 = 448? Or, bitmap_left is 0?
Moazin Khatri wrote:
> `Resvg' works with two graphic backends, `cairo' and `qt', so it would be
> interesting to look at how they calculate the bounding box. From a quick
> look, it looks like they use some recursive mechanism to calculate the
> bounding box of each element and then expanding it with every iteration until
> the final bounding box is calculated.
Yes, yes, it is good starting point for the implementers.
If we focus to the simple SVG consists from path objects (path, polygon,
polyline, ellipse, rectangle etc etc), the task is already completed. It would
not be so difficult in SVG Native Viewer, I hope.
But, if we want the renderer to calculate the bitmap_left of attached SVG as
448, instead of 0, finding a boundingbox without real drawing becomes difficult
task. If we deal a SVG including the raster image with alpha channel (and if we
hope as the transparent pixel in embedded image should be dealt as un-inked), it
would become more harder.
I confirmed that resvg_get_image_bbox() evaluates bitmap_left of the attached
SVG as 0 (the returned bbox is 1024 x 1024, instead of 64 x 64).
And, I confirmed that even cairo_recording_surface_ink_extents() evaluates the
bitmap_left as 0, either! Sigh.
Regards,
mpsuzuki
P.S.
I attached a program I used for the confirmation (it's a modified version of
resvg's example.c, to avoid GTK+).
simple-clip.svg
Description: simple-clip.svg
mini-example.c
Description: mini-example.c
- Re: [ft-devel] SVG Rendering Library, (continued)
- Re: [ft-devel] SVG Rendering Library, Werner LEMBERG, 2019/06/14
- 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
- Message not available
- Re: [ft-devel] SVG Rendering Library, suzuki toshiya, 2019/06/14
- Re: [ft-devel] SVG Rendering Library, suzuki toshiya, 2019/06/14
- Re: [ft-devel] SVG Rendering Library, Moazin Khatri, 2019/06/14
- Message not available
- Re: [ft-devel] SVG Rendering Library, suzuki toshiya, 2019/06/14
- 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/14
- Message not available
- Re: [ft-devel] SVG Rendering Library,
suzuki toshiya <=
- 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, 2019/06/15
- Re: [ft-devel] SVG Rendering Library, Moazin Khatri, 2019/06/15
- Re: [ft-devel] SVG Rendering Library, Werner LEMBERG, 2019/06/16