patternTransform browser implementations do not match spec

[AmeliaBR]

The definition of the SVG patternTransform attribute says (SVG 1.1)(SVG 2):

Contains the definition of an optional additional transformation from the pattern coordinate system onto the target coordinate system (i.e., 'userSpaceOnUse' or 'objectBoundingBox'). This allows for things such as skewing the pattern tiles. This additional transformation matrix is post-multiplied to (i.e., inserted to the right of) any previously defined transformations, including the implicit transformation necessary to convert from object bounding box units to local coordinate system.

In other words, when using objectBoundingBox units, a translation of 0.5,0.5 should shift the pattern tile by half the width and height of the box being painted. And a rotation around the point 0.5, 0.5 should be a rotation around the center of the box.

This is how it works with gradientTransform.

But none of the browsers apply it this way for patternTransform. Instead they always apply the transforms in user space coordinates. So a translation of 0.5,0.5 is just a shift of half a pixel in each direction.

But what's really weird is the rotate(45, 0.5,0.5) transform. It seems like it is rotating around the 0.5px,0.5px point of the user space coordinate system, not around the 0.5px,0.5px point of each tile or bounding box.

My guess is part of the problem is that there are two coordinate systems for patterns: the pattern tile (patternUnits) versus the pattern contents (patternContentUnits). So it's not really clear what should happen, according to spec, if the two unit types don't match each other, or if there is a viewBox on the pattern. I personally would expect the transform to apply to each composited pattern tile, in the units used to define the pattern tile dimensions. But that's not exactly spelled out in the spec.

But what I don't know is why no one ever brought up the issue with the spec so that it could get fixed.

So, something's gotta give. Either pave the erratic cowpath and spec what the browsers are doing (after first clearly figuring out what that is), or tighten up the definition and then file bugs on every browser. All of which is now made more complicated by the fact that patternTransform is supposed to also be affected by transform-origin and other CSS Transforms properties.

PS, Thanks to @yoksel for identifying this problem in her SVG Conundrum pen

[AmeliaBR]

PS, tested in Inkscape, it also does something weird but (just for fun) it is different from what the browsers are doing:

(Inkscape also doesn't like percentages for text positioning.)

[Tavmjong]

Inkscape generates patterns using 'userSpaceOnUse' so it would not be terribly surprising if there is a rendering error with 'objectBoundingBox'.

For consistency with all other transforms, the browsers should be fixed.

[nikosandronikos]

My guess is part of the problem is that there are two coordinate systems for patterns: the pattern tile (patternUnits) versus the pattern contents (patternContentUnits). So it's not really clear what should happen, according to spec, if the two unit types don't match each other, or if there is a viewBox on the pattern. I personally would expect the transform to apply to each composited pattern tile, in the units used to define the pattern tile dimensions. But that's not exactly spelled out in the spec.

It would be nice if the spec listed out all the transforms and the order they are applied in. The language in that section isn't very consistent. In some places it says transforms are 'post multiplied', in others it says 'applied on top'

This is how I've always thought of it (but disclaimer that I've never tested my understanding to this degree):
A conceptual pattern is created, which contains the geometry that exists in the rectangle defined by patternContentUnits or the viewBox, tiled to infinity.
Note: patternContentUnits is just a shorthand for two possible commonly used viewBox values)

Then that pattern is rendered onto the svg canvas, clipped by the the filled element.
The following transforms, listed in the spec, are applied to the pattern during rendering
U: user space
A: patternUnits*
C: patternTransform
F: final transformation matrix applied to the tile

the order of operations should be:
F = UABC

*userSpaceOnUse simply results in an identity matrix here.

My proposal is to leave the spec as is for now, but clarify in this issue what the behaviour should be. We need to create some tests covering this behaviour, then file bugs on the browsers and see if there is interest in fixing them. If there is, we tidy up the spec language, otherwise we spec what the browsers do as best we can.

[AmeliaBR]

On the 24 November 2016 telcon, we resolved:

pattern transforms are intended to work as described in SVG 1.1 (though clarification of some cases is required) - browser behaviour is wrong

We didn't think clarification required a normative change to the spec text. Instead, clarification should be pursued through the test suite, followed by browser bug reports.

We did agree that patternTransform applies to the pattern tile (i.e., in the coordinate system defined by patternUnits) and not to the pattern contents (scaled by viewBox or by patternContentUnits). This is consistent with how a transform on an <svg> applies, and makes patternTransform directly comparable to gradientTransform (although there is still the extra complication from each pattern tile being translated into place).

---

I looked at the SVG 1.1 test suite. The tests for patterns include a number marked "draft", which will need to be looked at separately, but for patternTransform there was only one test, which only tests a simple rotate(45) transform. In other words, it doesn't test whether the transform is applied before or after the conversion to object bounding box units.

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone