W3C home > Mailing lists > Public > www-svg@w3.org > May 2014

Re: Bounding box of a group with a transformed child

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Tue, 27 May 2014 14:37:11 +0200
To: www-svg@w3.org
Message-Id: <201405271437.11665.Dr.O.Hoffmann@gmx.de>
Paul LeBeau:
> It seems that pretty much all of the browsers, except FF, cheat and return
> the extent of the transformed-bbox.  Probably because calculating the true
> bbox of some elements (like complicated paths) is a little tricky.
>  Especially since the bbox needs to be calculated and available before any
> rendering takes place.  And in most cases it doesn't make a lot of
> difference if it is a little too big.
>
If you have for example:
<g stroke-width="10" stroke="url(#MyGradientUsingBoundingBoxUnits) red">
<path d="M0,0 1000,1000" transform="rotate(-45)" />
</g>
it would be a big difference.
If you determine the boundingBox before transformation:
'0 0 1000 1000' and apply the transformation to this rectangle:
'0 -1000/sqrt(2) 1000*sqrt(2) 1000*sqrt(2)'
correct:
'0 0 1000*sqrt(2) 0', this means, that one cannot apply for example
gradients and patterns with objectBoundingBox units to this - here
the stroke will be red instead of the gradient.

Indeed, even for rect elements the difference can be relevant:
<rect width="100" height="100" rx="50"  transform="rotate(-45)" />
This is as well a circle, the size in width and height of the boundingBox is
always 100 and not sqrt(2)*100.

And what about scaling?
<path d="M0,0 1000,1000" transform="scale(1,-1)" />
Will this 'cheating' result in '0 0 1000 -1000'? ;o)

More problems with skewing and general matrix transforms.
The difference can be of several orders of magnitude - or as
shown for the gradient example - arbitrary.
The cases, where the difference is not relevant, seem to be
the exceptions ;o)




If one has a good algorithm to determine the boundingBox of an object
without transformation, the extension to get it right for transformed objects
should be a solvable problem (because one only has to transform all points 
and control points of the equivalent paths of the objects and analyse this 
instead).
Obviously this is more difficult for the stroke of an object.


Olaf
Received on Tuesday, 27 May 2014 12:37:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:53 UTC