W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2008

Re: ISSUE-2021 (image-bbox): Bounding box of <image> subject to aspect-ratio preservation undefined [SVG Tiny 1.2]

From: Erik Dahlström <ed@opera.com>
Date: Tue, 22 Jul 2008 08:51:04 +0200
To: "SVG Working Group WG" <public-svg-wg@w3.org>
Message-ID: <op.ueolbem0gqiacl@gnorps.linkoping.osa>

On Fri, 18 Jul 2008 07:32:23 +0200, SVG Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:

> ISSUE-2021 (image-bbox): Bounding box of <image> subject to aspect-ratio preservation undefined [SVG Tiny 1.2]
> http://www.w3.org/Graphics/SVG/WG/track/issues/
> Raised by: Cameron McCormack
> On product: SVG Tiny 1.2
> The spec doesn't really define what the bounding box of an <image> is.  The non-obvious case is when preserveAspectRatio="" is set so that the image doesn't take up the whole area specified on the <image> element.
> Test:
>   http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/image-bbox.svg
> In Firefox 3 and Opera 9.5, the bounding box is [0,0,400,400].  In Batik 1.7, it's [100,0,200,400].  I suppose I would prefer the latter, since it lets you determine the aspect ratio of the image from script.

This may not affect tiny, but in 1.1 full:
What if a referenced svg image extends outside of its viewbox? Would you expect the boundingbox to be tightly fitting the referenced image (including the overflowing parts), or to return the viewbox rect that was positioned inside the viewport defined by the <image> element? Or if there was no viewbox, but the image had width/height defined and there was some overflow. And would you expect the 'overflow' property to affect the boundingbox in such cases?

Since the change you propose can also affect things like clipping, filters and masks (that can depend on the boundingbox of the image) I'm wondering if you have seen any problems with this in Batik.


Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 22 July 2008 06:53:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:09 UTC