W3C home > Mailing lists > Public > www-svg@w3.org > February 2003

Re: getScreenCTM (again)

From: Thomas E Deweese <thomas.deweese@kodak.com>
Date: Sat, 8 Feb 2003 07:48:03 -0500
Message-ID: <15940.64643.518931.303801@frog.rl.kodak.com>
To: Sigurd Lerstad <sigler@bredband.no>
Cc: Thomas E Deweese <thomas.deweese@kodak.com>, www-svg@w3.org

Hi Sigurd,

>>>>> "SL" == Sigurd Lerstad <sigler@bredband.no> writes:

SL> Wouldn't it be more useful if getBBox returned the bounding box
SL> BEFORE any transform, since you can always apply that afterwards
SL> to the BBox, but you can't unapply it. (or am I missing
SL> something?)

>>  You can generally apply the inverse of the transform.

SL> My understanding is that what will no longer give the tightest
SL> bounding box.

    This is correct, but this is an issue no matter what coordinate
system you return the BBox in.  So in your example if you want to real
BBox of the ellipse, as opposed to the BBox in it's parent coordinate
system, you have the same error.

    While the 'untransformed' bounds of an ellipse might be reasonably
easy to calculate from the attributes this is not very true of a path

    What I think you really want is some sort of
getTransformedBBox(SVGLocatable other) method that transforms the
geometry to the coordinate system of 'other' via
getTransformToElement, then the 'tight' BBox is calculated in that
coordinate system.

SL> Say you have an ellipse with a transformation.

SL> A bbox(1) before transformation gives the tightest bbox, you can
SL> then transform each point of that bbox and you get a new bbox
SL> after transformation.

SL> However:

SL> If you only get a bbox(2) after transformation, and you apply
SL> inverse transform to each point of that bbox, then you get a new
SL> bbox, but that bbox will not be the same as bbox(1)

SL> Since you don't keep the transformed points of the bbox around,
SL> you keep the "bounding box" of the transformed points.

SL> (Okay, I'm not sure you understand what I mean :)

SL> -- Sigurd Lerstad
Received on Saturday, 8 February 2003 07:50:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:55 UTC