- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Tue, 27 May 2014 14:37:11 +0200
- To: www-svg@w3.org
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