paste style doesn't keep relative gradient position

[Popolon2]

paste style doesn't keep relative gradiant position

Create an object (circle, rectangle...), fill it with a
radial or linear gradiant
copy it to buffer (ctrl+c)

create another object at another place in the document
paste the style (ctrl+shift+v)

the gradient keep the document absolute coordinates
position, instead of the object relative one (then is
generaly far outside of the new object).

jully 16 CVS version

[Buliabyak-users (buliabyak-users)]

This is not a bug. It's designed to be that way. The current
behavior is more often (or at least as often) useful as what
you propose. If you need, as an option, the paste style
command to move gradient to the new object's bbox, file a
RFE for it.

It's all explained and discussed here:

https://sourceforge.net/mailarchive/message.php?msg_id=9779596

[Guillermo Espertino (Gez) (gespertino-gmail)]

This design choice can be considered a usability bug, since it's totally counter-intuitive.
When the user pastes the "style" on a new element he expects that the result is an object with the same style of the referenced.
And for the user/artist the "style" refers to the appearance, not the internals of the SVG file.
If I have a vertical gradient from red to yellow on the top of the page and want the same "style" of fill for a rectangle that is at the bottom of the page, I want the same gradient, not a solid yellow fill.
The result is something unexpected and if the gradient widget is off-screen and the user can't see it, it's very hard to understand what's happening. And that, in my oppinion, makes it a bug.

[su_v (suv-lp)]

another user report about "losing" gradients when using 'paste style':
<https://bugs.launchpad.net/inkscape/+bug/165515/comments/1>

[Pablo Trabajos (pajarico)]

Why not make this a matter of preferences based on "move gradients" setting in the selector toolbar?

[Dimitris Glezos (glezos)]

This sounds like a nice-to-have configuration choice. Users kind-of "expect" when they copy-paste the style of an object to see the same background in the pasted object, and seeing e.g. "white" makes the first reaction to be "This didn't work".

If I understand correctly, this means that pasting the style will need to copy the gradient and move it appropriately.

Hope this helps.

[Olof Bjarnason (objarni)]

I agree with Pablo/Guillermo: I keep stumpling on this "feature". When copying from a rotated object with a gradient, it is even more confusing:

1. F4: Draw a rectangle
2. g + double click rectangle: Put a gradient-fill left-to-right over it
3. F1: Rotate the rectangle
4. Ctrl+C: Copy rectangle to clipboard
5. F4: Draw another rectangle
6. Ctrl+Shift+V: Paste style to new rectangle
7. g: Notice how the gradient handles are not placed at the same (absolut) coordinates as in the first rectangle.

Whenever I paste gradient styles, I keep looking for those gradient handles way off in the drawing. It just does not seem intuitive, the current behaviour. Also, in "The book of Inkscape" (by Dmitry Kirsanov) I cannot find a clear statement on what kind of behaviour I should expect from the gradient handles when pasting style.

[Christian Loch (christian-loch)]

There is obviously code that was supposed to lead to the behavior, that many users would expect.

When you copy/paste a path with style, the copied linearGradient gets a "gradientTransform" attribute containing a "translate" to the new path's position. Thus, the copied gradient stays in the same position relative to the copied path.

When you paste a style to a different path, there is also created a linearGradient with a grandientTransform=translate attribute - but it is not assigned to the target object. Instead, the intermediate gradient to which the translated gradient points to is assigned to the target path.

So, in the SVG, we get a rogue gradient that would - if used - align the copied gradient to the upper right corner of the target object, but it is not used.

[grey tomorrow (gtomorrow)]

Hi - thanks for reporting this bug, I've manually migrated it to Inkscape's new bug tracker on GitLab, and closed it here.

Please feel free to file new bugs about the issues you're seeing at
https://inkscape.org/report .

Moved to: https://gitlab.com/inkscape/inbox/-/issues/3499
Closed by: https://gitlab.com/greytomorrow