Gradients with objectBoundingBox coordinates not being preserved or rendered correctly
If I create a gradient in Inkscape, the default coordinate space is userSpaceOnUse, as opposed to objectBoundingBox (see https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/gradientUnits).
This is ok, but if I edit a gradient manually (via a text editor or the XML editor) to change it to objectBoundingBox coordinates, I would like it to stay that way.
objectBoundingBox gradients are very useful if you want to animate or otherwise interact with the SVG using javascript in a browser -- the gradient will move relative to the object, and you don't have to write extra complicated code to try and keep it lined up.
Currently, *a)* Inkscape initially renders the gradient nodes in the correct position, but does not render the gradient colours themselves. So the object has a flat colour. *b) *As soon as I drag one of the endpoints, it reverts to userSpaceOnUse coordinates.
Which means that it becomes quite difficult to edit my SVG file in Inkscape ever after! Ideally, the object would be coloured correctly, and if I move a node or endpoint, it would remain in objectBoundingBox coordinates.
Better yet, there would be a way to switch to objectBoundingBox coordinates from within the GUI, to avoid having to calculate the conversion maths in the XML editor.
How hard would those things be to fix?
- Bryan
On 2013-10-31 04:20 +0200, Bryan Hoyt | Brush Technology wrote:
If I create a gradient in Inkscape, the default coordinate space is userSpaceOnUse, as opposed to objectBoundingBox (see https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/gradientUnits).
This is ok, but if I edit a gradient manually (via a text editor or the XML editor) to change it to objectBoundingBox coordinates, I would like it to stay that way.
objectBoundingBox gradients are very useful if you want to animate or otherwise interact with the SVG using javascript in a browser -- the gradient will move relative to the object, and you don't have to write extra complicated code to try and keep it lined up.
Currently, *a)* Inkscape initially renders the gradient nodes in the correct position, but does not render the gradient colours themselves. So the object has a flat colour.
Please attach a sample SVG file - based on your other email I guess this refers to Inkscape trunk, too: which revision of trunk are you currently using?
Note: there had been regressions wrt to rendering gradients which use 'objectBoundingBox' in trunk (rev >= 12528), but AFAIK those have been fixed again (rev >= 12646).
*b) *As soon as I drag one of the endpoints, it reverts to userSpaceOnUse coordinates.
Inkscape only supports 'userSpaceOnUse' when writing gradient definitions.
Which means that it becomes quite difficult to edit my SVG file in Inkscape ever after! Ideally, the object would be coloured correctly, and if I move a node or endpoint, it would remain in objectBoundingBox coordinates.
Better yet, there would be a way to switch to objectBoundingBox coordinates from within the GUI, to avoid having to calculate the conversion maths in the XML editor.
Ok, the latest trunk (0.48+devel+12780+44~ubuntu13.04.1) renders objectBoundingBox gradients correctly.
However, as su_v pointed out, Inkscape doesn't really support these when editing. As soon as I edit the gradient on-canvas, or move the object associated with the gradient, the gradient immediately reverts to userSpaceOnUse. This is pretty annoying, because it takes a little while to set up the coordinates by hand, only to have Inkscape destroy them on the slightest interaction.
I guess this is a "feature not a bug", in that I'm using Inkscape in a slightly unusual way. However, I'd be keen to (have someone) add a feature to allow this usage. Could anyone give me some pointers on where to start looking in the code, how big a job this might be, and perhaps if there is someone else out there who might be keen to implement the feature?
- Bryan
On Thu, Oct 31, 2013 at 11:12 PM, su_v <suv-sf@...58...> wrote:
On 2013-10-31 04:20 +0200, Bryan Hoyt | Brush Technology wrote:
If I create a gradient in Inkscape, the default coordinate space is userSpaceOnUse, as opposed to objectBoundingBox (see
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/gradientUnits).
This is ok, but if I edit a gradient manually (via a text editor or the XML editor) to change it to objectBoundingBox coordinates, I would like it to stay that way.
objectBoundingBox gradients are very useful if you want to animate or otherwise interact with the SVG using javascript in a browser -- the gradient will move relative to the object, and you don't have to write extra complicated code to try and keep it lined up.
Currently, *a)* Inkscape initially renders the gradient nodes in the correct position, but does not render the gradient colours themselves. So the object has a flat colour.
Please attach a sample SVG file - based on your other email I guess this refers to Inkscape trunk, too: which revision of trunk are you currently using?
Note: there had been regressions wrt to rendering gradients which use 'objectBoundingBox' in trunk (rev >= 12528), but AFAIK those have been fixed again (rev >= 12646).
*b) *As soon as I drag one of the endpoints, it reverts to userSpaceOnUse coordinates.
Inkscape only supports 'userSpaceOnUse' when writing gradient definitions.
Which means that it becomes quite difficult to edit my SVG file in Inkscape ever after! Ideally, the object would be coloured correctly, and if I move a node or endpoint, it would remain in objectBoundingBox coordinates.
Better yet, there would be a way to switch to objectBoundingBox coordinates from within the GUI, to avoid having to calculate the conversion maths in the XML editor.
Hi Bryan,
The problem was brought up last week on the list.
On Fri, 2013-11-08 at 09:04 +1300, Bryan Hoyt | Brush Technology wrote:
I guess this is a "feature not a bug", in that I'm using Inkscape in a slightly unusual way. However, I'd be keen to (have someone) add a feature to allow this usage. Could anyone give me some pointers on where to start looking in the code, how big a job this might be, and perhaps if there is someone else out there who might be keen to implement the feature?
I'm interested in evaluating your keenness. Are you saying you wish to sponsor someone to work on the codebase to enable the feature for you? We don't have a way to connect developers up to keen users yet (although it's something I think we should do).
But maybe if you lay what you expect and how people can contact you to sort out any details off list. That would be a good place to start.
Best Regards, Martin Owens
I'm suggesting that I'd be happy to have a go at fixing it myself at some stage in the nearish future, if it's not likely to be a big project, but if there were someone else who was keen to do it, I'd be happy to let them! I'm not offering sponsorship.
My thoughts on how such a set of features should work: 1) When editing the nodes of an objectBoundingBox gradient, it remains in objectBoundingBox coordinates in the XML representation, but with no visual change in behaviour. 2) When moving or resizing an object associated with an objectBoundingBox gradient, the gradient's XML representation remains unchanged. 3) We add a toolbar button (or preference or document option) to switch gradients (or a given gradient) between objectBoundingBox and userSpaceOnUse coordinates.
I know C++ well, but don't know Inkscape's codebase. Am I looking at a 2-day project or a 2-week (or 2-month) project?
- Bryan
On Fri, Nov 8, 2013 at 9:28 AM, Martin Owens <doctormo@...400...> wrote:
Hi Bryan,
The problem was brought up last week on the list.
On Fri, 2013-11-08 at 09:04 +1300, Bryan Hoyt | Brush Technology wrote:
I guess this is a "feature not a bug", in that I'm using Inkscape in a slightly unusual way. However, I'd be keen to (have someone) add a feature to allow this usage. Could anyone give me some pointers on where to start looking in the code, how big a job this might be, and perhaps if there is someone else out there who might be keen to implement the feature?
I'm interested in evaluating your keenness. Are you saying you wish to sponsor someone to work on the codebase to enable the feature for you? We don't have a way to connect developers up to keen users yet (although it's something I think we should do).
But maybe if you lay what you expect and how people can contact you to sort out any details off list. That would be a good place to start.
Best Regards, Martin Owens
On Fri, 2013-11-08 at 10:02 +1300, Bryan Hoyt | Brush Technology wrote:
I'm suggesting that I'd be happy to have a go at fixing it myself at some stage in the nearish future, if it's not likely to be a big project, but if there were someone else who was keen to do it, I'd be happy to let them! I'm not offering sponsorship.
Oh, no problem, I just read "I'd be keen to (have someone) add" as that because to have someone is basically to have them work on your behalf.
Anyway! I have some ideas for you regarding getting into the code.
I know C++ well, but don't know Inkscape's codebase. Am I looking at a 2-day project or a 2-week (or 2-month) project?
You're not just going to be learning codebase, there's also a bit of a process to committing at first when you don't have commit access.
The best way to learn what you need to learn is to keep the website documentation open:
http://staging.inkscape.org/en/develop/getting-started/
And pick some bugs with the blending or similar areas from the list of bug reports:
http://tiny.cc/q3y34w <- these ones first, then any other
Fixing these issues will get you more familiarity with the codebase as well as commit access to trunk. Although I recommend keeping the branch/merge process for larger tasks as it makes it easier to review.
Good luck Bryan, let us know if you need any help.
Best Regards, Martin Owens
On Thu, Nov 7, 2013 at 1:02 PM, Bryan Hoyt | Brush Technology <bryan@...2310...> wrote:
I'm suggesting that I'd be happy to have a go at fixing it myself at some stage in the nearish future, if it's not likely to be a big project, but if there were someone else who was keen to do it, I'd be happy to let them! I'm not offering sponsorship.
I wouldn't be surprised if the code involving all of this hasn't drastically changed... but here's the commit that removed the old toggle that existed.
http://sourceforge.net/p/inkscape/code/5564/ and there were 2 commits before and 1 after related to this change.
I'm not saying you should by any means attempt a copy and paste job, but referencing this and the surrounding commits will probably get you into the right area of the codebase.
Cheers, Josh
Thanks for the useful info, Martin & Josh. I'll see how far I get. -Bryan
On Fri, Nov 8, 2013 at 11:11 AM, Josh Andler <scislac@...400...> wrote:
On Thu, Nov 7, 2013 at 1:02 PM, Bryan Hoyt | Brush Technology <bryan@...2310...> wrote:
I'm suggesting that I'd be happy to have a go at fixing it myself at some stage in the nearish future, if it's not likely to be a big project, but
if
there were someone else who was keen to do it, I'd be happy to let them!
I'm
not offering sponsorship.
I wouldn't be surprised if the code involving all of this hasn't drastically changed... but here's the commit that removed the old toggle that existed.
http://sourceforge.net/p/inkscape/code/5564/ and there were 2 commits before and 1 after related to this change.
I'm not saying you should by any means attempt a copy and paste job, but referencing this and the surrounding commits will probably get you into the right area of the codebase.
Cheers, Josh
2013/11/7 Bryan Hoyt | Brush Technology <bryan@...2310...>:
I'm suggesting that I'd be happy to have a go at fixing it myself at some stage in the nearish future, if it's not likely to be a big project, but if there were someone else who was keen to do it, I'd be happy to let them! I'm not offering sponsorship.
My thoughts on how such a set of features should work:
- When editing the nodes of an objectBoundingBox gradient, it remains in
objectBoundingBox coordinates in the XML representation, but with no visual change in behaviour. 2) When moving or resizing an object associated with an objectBoundingBox gradient, the gradient's XML representation remains unchanged.
Strictly speaking, these two requirements are incompatible. When you rotate or skew an object, an objectBoundingBox gradient has to be modified in a non-obvious way so that it transforms with the object. In fact handling rotations and skew would probably be the hardest part of implementing this.
The relevant places are:
1. SPItem::adjust_gradient, src/sp-item.cpp line 1124 2. sp_gradient_convert_to_userspace, src/gradient-chemistry.cpp line 430 3. sp_gradient_transform_multiply, src/gradient-chemistry.cpp line 549
Regards, Krzysztof
- When editing the nodes of an objectBoundingBox gradient, it remains in
objectBoundingBox coordinates in the XML representation, but with no
visual
change in behaviour. 2) When moving or resizing an object associated with an objectBoundingBox gradient, the gradient's XML representation remains unchanged.
Strictly speaking, these two requirements are incompatible. When you rotate or skew an object, an objectBoundingBox gradient has to be modified in a non-obvious way so that it transforms with the object.
Understood. I would do a simple first-pass by just making it work in non-rotated-or-skewed scenarios. Those scenarios are my biggest source of surprise & annoyance -- for eg when I simply shift an object to a different place on the canvas, I find it surprising that I've messed up my gradient type. But if I rotate or (especially) skew, I can accept that things will not be as simplistic.
That said, I'm vaguely imagining that it would be a case of doing the necessary calculations in userSpace coordinates (or canvas coordinates), and converting back to boundingBox coordinates via the transform matrix etc. Perhaps I'll find out it's not so straightforward when I get to it.
The relevant places are:
Thanks!
- Bryan
participants (5)
-
Bryan Hoyt | Brush Technology -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
su_v