incubator-ooo-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 120616] svg: wrong rendering for gradientUnits="objectBoundingBox"
Date Thu, 23 Aug 2012 11:32:18 GMT

Armin Le Grand <> changed:

           What    |Removed                     |Added
             Status|UNCONFIRMED                 |ACCEPTED
     Ever confirmed|0                           |1

--- Comment #5 from Armin Le Grand <> ---
ALG: Problem is completely different from what I thought. First, #120397# was
not the right fix and I took it back.
The general problem is that gradients use gradientUnits as objectBoundingBox or
userSpaceOnUse. Both define in which coordinate system the data is to be
interpreted, thus it is possible to map both to the unit coordinate system
(0,0,1,1) relative to an object (by mapping start/end/radius, etc.). That's
what I did with the primitive representation for SVG gradients. The
gradientTransform makes no difference here, it can be included to the mapping.
But it is differently interpreted by SVG:

(a) When gradientUnits, the gradient is interpreted in unit coordinates and
then transformed using the object transformation.
(b) When userSpaceOnUse, the gradient is interpreted in world coordinates
(first apply oblect transformation, then interpolate).

Case (a) leads to the gradient being 'scaled' to the object's aspect ratio,
since the object transformation is applied to gradient data in unit
coordinates. Case (b) will keep the aspect ratio of the object unrecognized
since interpreted after the object transform is applied.

Thus, in reality, SVG has four different kind of gradients, not two. I did not
see this clearly stated/explained in SVG1.2 spec, maybe I overlooked it.

The solution is to give the gradient primitive a flag in which order the object
transformation and the gradient interpretation has to be done. Done that, works
well. I'll add an example with all four cases.

One remark on primitive usage: Luckily I have only to adapt two primitives to
change this, it is just differently decomposed to primitive atoms (one color
range only); without primitives there would be implementations in each
viewer/exporter (PDF, vcl, convert to bitmap, break, ...) which would need to
be changed...

You are receiving this mail because:
You are the assignee for the bug.

View raw message