Circular gradient in skewed object: axes' angle changes upon transformation

[Bart Van Audenhove]

To reproduce:
- make a rectangle
- skew it
- change fill to circular gradient
- switch to gradient tool. (The axes of the gradient are not at 90° angle but skewed also. This is not exactly a bug, see ~suv comments below)
- drag the endpoints of the gradient's axes out: the angle between the axes becomes gradually smaller, making the gradient unusable.
See attached animated GIF of screenshots.

[Bart Van Audenhove (bart-vanaudenhove)]

Main problem is that the angle between the gradient axes changes when dragging their endpoints out.

If the gradient axes would *remain* at an angle that corresponds to the "skew angle" (angle between skewed rectangle sides), it could be desirable behaviour. But with the angle changing, the gradient becomes unusable.

[su_v (suv-lp)]

On 2015-11-26 19:47 (+0100), Bart Van Audenhove wrote:
> Skew deforms circular gradient axes

This in itself is not a bug - it's basically how SVG works: style properties (e.g. fill paint, or even stroke width) of an object with a preserved transform attribute (it might be skewed, or e.g. scaled) are subjected to the same transformation (i.e. painting is done before applying a transformation defined in the 'transform' attribute or inherited from a parent container element (e.g. a group) to the object as a whole).

The select tool has a toggle button which controls whether or not gradients are transformed along with the object or not. The underlying technical details vary depending on whether or not the skew transformation is stored in a preserved 'transform' attribute of the object itself (or one of the parent container elements), always based on the above behavior as defined in the SVG specs (paint before transform).

The select tool has no third option specifically for gradients to automagically apply yet another sort-of-inverse transformation to the gradient in use for a transformed object to appear as if the gradient definition would define orthogonal handles (i.e. rotated, and with different, adjusted lengths for both radii) in the current coordinate system, while actually applied and subjected to the object's own transform. This might be considered a missing feature - if feasible at all to implement and to support with whatever editing can occur at any time later on to the object, any parent container elements as well as to the gradient itself (I can't tell).

[su_v (suv-lp)]

> - drag the endpoints of the gradient's axes out: the angle between
> the axes becomes gradually smaller, making the gradient unusable.

This AFAICT is a bug - the object's own preserved transformation (and/or the one of the parent object if a wrapping group is skewed instead of the object itself) and any transformation already applied to the gradient definition itself is incorrectly compensated/recalculated when modifying the gradient's geometry while applied with a transformation in effect.

These unexpected (AFAICT incorrect) transforms of such edited skewed gradients reproduce with Inkscape 0.47, 0.48.5, 0.91 as well as latest 0.91+devel r14494 (tested on OS X 10.7.5).

I will later attach a test case (SVG file) which allows to compare expected and unexpected (AFAICT incorrect) movements of the opposite handle when dragging the other one while the gradient is applied to a skewed object (or to an object inside a skewed group) - (a set of examples with different defined movements of one of the two handles is on my TODO list).

I would recommend to change the report's summary line to reflect the actual bug (any feature request for (sometimes, or optionally) automagically unskewed "optimized" orthogonal radial gradients painted for skewed objects should be filed and tracked separately).

[Bart Van Audenhove (bart-vanaudenhove)]

Thanks for clarifying ~suv. Bug title changed according to your recommendations above. Also description slightly edited for same reason.

I personally don't see much need for an option/feature request to "unskew" the gradient. (See eg. http://www.inkscapeforum.com/viewtopic.php?f=5&t=20098#p76255 for a workaround).
The bug (axes' angle changing) does seem worth fixing IMO.