Re: Percentage on objectBoundingBox

On Thu, 2014-01-23 at 12:52 +0000, Dirk Schulze wrote:
> Hi,
> 
> I had an action to check the behavior of percentage values on objectBoundingBox.
> 
> More specific: An element is a descendant of a <mask>, <clipPath> or <pattern>. The <mask>, <clipPath> or <pattern> have the attribute maskContentUnits, clipPathUnits or patternContentUnits set to “objectBoundingBox”. How are percentage on the element resolved.
> 
> Introduction
> =========
> 
> Just as ramp up, for objectBoundingBox, the reference box is assumed to have 1 unit width and 1 unit height. The resulting clipPath, mask or pattern is then scaled to the object bounding box of the referencing element.
> 
> Example:
> 
> <svg width=“600” height=“600">
> <clipPath clipPathUnits=“objectBoundingBox” id=“clip">
>     <ellipse cx=“0.5” cy=“0.5” rx=“0.5” ry=“0.5"/>
> </clipPath>
> 
> <rect width=“150” height=“300” clip-path=“url(#clip)”/>
> </svg>
> 
> The result will be an ellipse similar to <ellipse cx=“75” cy=“150” rx=“75” ry=“150”/>.
> 
> Now I want to use percentage for the clipping path. Which value would I need to chose to get the same result? According to the spec (at least it seems), percentage should be relative to the viewport (independent of the clipPathUnits value).
> 
> The viewport has a width and height of 600 units. The resulting clipping ellipse should look like this:
> 
> <ellipse cx=“12.5%” cy=“25%” rx=“12.5%” ry=“25%”/>
> 
> 12.5% = 75 * 1 / 600 (width of viewport)
> 25% = 150 * 1 / 600 (height of viewport)
> 
> Note: If the ellipse in the clipPath would be a circle, we would run into a problem, since the aspect ratio between the rect (1:2) is not corresponding to the one of the svg (1:1) and we have a circle where we just can specify one radius.
> 
> Implementations
> ============
> 
> * Illustrator sometimes follows the spec but not for the example above.
> * All browsers + Batik
> Browsers are interoperable but do not follow the spec. In fact, for all browsers the following values create the same result as in the initial example:
> 
> <ellipse cx=“0.08333%” cy=“0.08333%” rx=“0.08333%” ry=“0.08333%”/>
> 
> At the beginning, browsers follow the spec:
> 
> 12.5% = 75 * 1 / 600 (width of viewport)
> 25% = 150 * 1 / 600 (height of viewport)
> 
> But since the values are relative to the object bounding box, the results are scaled to the boundaries of the referencing element.
> 
> 0.08333% = 75 * 1 / 600 (width of viewport) * 1 / 150 (width of <rect>)
> 0.08333% = 150 * 1 / 600 (height of viewport) * 1 / 300 (height of <rect>)
> 
> * Inkscape didn’t accept any of the values. The whole content was clipped away for all percentage examples.

Inkscape trunk does agree with the browsers for rendering... but doesn't
actually generate clip-paths with percentages. Batik Squiggle renders as
the browsers too.

> Conclusion
> ========
> 
> * None of the UAs follow the specification as the SVG WG interpreted the spec in the last call.
> * Especially authoring tools expect something different than UAs display.
> 
> Even if browsers are interoperable, I do not believe that the way percentages are handled is particularly useful for authors.
> Since no UA follows the spec, it wouldn’t harm to change the spec.
> Since (IMO), the behavior of browsers isn’t great, the WG can come up with a better solution for resolving percentage values. A suggestion is to follow the CSS specification and resolve percentage to a reference box. I suggest that the reference box for userSpaceOnUse will be the viewport (as it is today). The reference box for objectBoundingBox will be the object bounding box of the referencing element. This would also harmonize the usage of percentage on the content with the usage on the x, y, width and height attributes of <mask>, <pattern> and <filter>.

I would agree that as an author I would expect percentages to be with
respect to the bounding box. It seem strange to have to recalculate the
attributes when the width/height of the SVG drawing changes. I would
agree with the proposed change if it doesn't break significant content.

This behavior would be important for defining "ports" with connectors.

One additional point, I would expect the bounding box to be calculated
before any transforms are applied (e.g. rotation). The browsers and
Inkscape do this but the rsvg renderer does not. This should be made
clear in the spec. See test.[1]

Tav

http://tavmjong.free.fr/SVG/BOUNDINGBOX/reference_box.svg

Received on Tuesday, 28 January 2014 13:40:09 UTC