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

Re: Percentage on objectBoundingBox

From: Erik Dahlström <ed@opera.com>
Date: Thu, 23 Jan 2014 15:47:03 +0100
To: "www-svg@w3.org" <www-svg@w3.org>, "Dirk Schulze" <dschulze@adobe.com>
Message-ID: <op.w9490pecdhsuf5@gnorps>
 From http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBoxUnits:

[[
When keyword objectBoundingBox is used, then the effect is as if a  
supplemental transformation matrix were inserted into the list of nested  
transformation matrices to create a new user coordinate system.

First, the (minx,miny) and (maxx,maxy) coordinates are determined for the  
applicable element and all of its descendants. The values minx, miny, maxx  
and maxy are determined by computing the maximum extent of the shape of  
the element in X and Y with respect to the user coordinate system for the  
applicable element. The bounding box is the tightest fitting rectangle  
aligned with the axes of the applicable element's user coordinate system  
that entirely encloses the applicable element and its descendants. The  
bounding box is computed exclusive of any values for clipping, masking,  
filter effects, opacity and stroke-width. For curved shapes, the bounding  
box encloses all portions of the shape, not just end points. For ‘text’  
elements, for the purposes of the bounding box calculation, each glyph is  
treated as a separate graphics element. The calculations assume that all  
glyphs occupy the full glyph cell. For example, for horizontal text, the  
calculations assume that each glyph extends vertically to the full ascent  
and descent values for the font.

Then, coordinate (0,0) in the new user coordinate system is mapped to the  
(minx,miny) corner of the tight bounding box within the user coordinate  
system of the applicable element and coordinate (1,1) in the new user  
coordinate system is mapped to the (maxx,maxy) corner of the tight  
bounding box of the applicable element. In most situations, the following  
transformation matrix produces the correct effect:
[ (maxx-minx) 0 0 (maxy-miny) minx miny ]

When percentages are used with attributes that define the gradient vector,  
the pattern tile, the filter region or the masking region, a percentage  
represents the same value as the corresponding decimal value (e.g., 50%  
means the same as 0.5). If percentages are used within the content of a  
‘pattern’, ‘clipPath’, ‘mask’ or ‘filter’ element, these values are  
treated according to the processing rules for percentages as defined in  
Units.
]]

I wonder if the first paragraph influenced the observed behavior.

I think it would be nice if it was possible to use both viewport-relative  
and objectbbox-relative values inside a clipPath. However, I am slightly  
concerned that this would break content that relies on the current browser  
behavior.

In 2008 roc wrote that authors then expected the percentages in this  
particular case to be relative to the OBB, not to the viewport:  
http://lists.w3.org/Archives/Public/www-svg/2008May/0048.html.

So, it looks like ISSUE-2013 has been rediscovered, and I assume your  
investigation means you want to take over ACTION-2077.


On Thu, 23 Jan 2014 13:52:58 +0100, Dirk Schulze <dschulze@adobe.com>  
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.
>
> 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>.
>
> Greetings,
> Dirk
>
>
> On Jan 3, 2014, at 8:53 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>
>> Hi,
>>
>> I checked the behavior of objectBoundingBox on content with percentage  
>> values:
>>
>> <clipPath clipPathUnits="objectBoundingBox" id="clip1">
>> <circle cx="0.5" cy="0.5" r="0.5"/>
>> </clipPath>
>> <clipPath clipPathUnits="objectBoundingBox" id="clip2">
>> <circle cx="50%" cy="50%" r="50%"/>
>> </clipPath>
>>
>>> From the section “Object bounding box units” in SVG 1.1 [1] I would  
>>> assume that both clipping paths do exactly the same. And yet, all SVG  
>>> viewers seem to hide content completely clipped with the second  
>>> clipping path.
>>
>> “”
>> If percentages are used within the content of a ‘pattern’, ‘clipPath’,  
>> ‘mask’ or ‘filter’ element, these values are treated according to the  
>> processing rules for percentages as defined in Units.
>> “”
>>
>> The section about Units[2] say that percentage are resolved to the  
>> nearest viewport.
>>
>> “”
>> The three rectangles on the right demonstrate the use of percentages.  
>> Note that the width and height of the viewport in the user coordinate  
>> system for the viewport element (in this case, the outermost svg  
>> element) are 4000 and 2000, respectively, because processing the  
>> ‘viewBox’ attribute results in a transformed user coordinate system
>> “”
>>
>> Of course it depends if <pattern>, <mask>, <clipPath> and so on create  
>> a new viewport. I am not sure if that is ever explicitly said.  
>> Especially for userSpaceOnUse we take the nearest viewport of the  
>> affected element. Even though, what does it mean for the example above?
>>
>> Greetings,
>> Dirk
>>
>> [1] http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox
>> [2] http://www.w3.org/TR/SVG11/coords.html#Units
>> <clip-path.svg>
>
>


-- 
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Received on Thursday, 23 January 2014 14:47:39 UTC

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