Gradient issues with ungrouped image library images

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Insert from image library - I have tried several that have the same problem, 
but I know this one shows the problem for sure - Flora>Mangroves>Bruguiera 
gymnorrhiza flower
2. Ungroup twice
3.

What is the expected output? What do you see instead?
Ungrouped but looking the same. Gradient fill gets messed up.

In what browser did you experience this problem? (ALL, Firefox, Opera 10
Alpha, etc)
Only tested FF

Please provide any additional information below.
Also, if you insert another copy of the same image, the newly inserted one has 
the same gradient issues even without ungrouping. Also, moving one affects the 
position of the gradient of the other one. Also, and slightly unrelated, on 
ungrouping, the stroke thickness increases. I am guessing that the gradient 
issues are related to Issue 469.

Original issue reported on code.google.com by adrianbj...@gmail.com on 23 Jul 2010 at 5:40

[GoogleCodeExporter]

Could you attach the related file to issues like these? That'd make debugging a 
little easier. 

Original comment by adeve...@gmail.com on 27 Jul 2010 at 3:15

• Changed state: Accepted
• Added labels: Interoperability

[GoogleCodeExporter]

Sorry about that. I have attached the file, but note that the behavior is 
different depending on how you get this file into svg-edit.

Open Image: no gradient works

Import SVG: gradient works, but due to the userSpaceOnUse issue, it is lost 
when you move the image

Import via image library - as I described above.

Original comment by adrianbj...@gmail.com on 27 Jul 2010 at 3:42

Attachments:

• iil-symbol-bruguiera-gymnorrhiza-flower.svg

[GoogleCodeExporter]

Issue 644 has been merged into this issue.

Original comment by adeve...@gmail.com on 9 Sep 2010 at 1:33

[GoogleCodeExporter]

Just thought I'd let you know that I have added an "Edit in svg-edit" button 
for all vectors in our image library, which should make life easier for seeing 
the different behavior of gradients when opening vs importing via svg-edit's 
image library extension.

For example, here is the link to the flower example in our image library:
http://ian.umces.edu/imagelibrary/displayimage-search-4552.html

Once you log in, you'll see an "Edit Online" button, just below the download 
link.

Just playing around with this I noticed something new. Try this:

1) Click the "Edit Online" button from the above link. Note the lack of 
gradients
2) Without clearing the canvas, import the same flower image 
(Flora>Mangroves>Bruguiera gymnorrhiza flower) from the svg-edit IAN image 
library. See how the gradient has been added to the original opened instance of 
the flower.

Anyway, thought something there might prove useful :)

Original comment by adrianbj...@gmail.com on 14 Sep 2010 at 12:26

[GoogleCodeExporter]

3) Break link to reference element and now the originally opened instance loses 
its gradient, but the imported one doesn't - weird!

Original comment by adrianbj...@gmail.com on 14 Sep 2010 at 12:28

[GoogleCodeExporter]

I am sure you realize this already, but I took a quick look at what is going on 
with the SVG at each stage of my example above and it definitely relates to the 
userSpaceOnUse issue. Importing from the image library (step 2 from above) 
redefines the gradients at the top of the svg code and keeps the 
gradientUnits="userSpaceOnUse", which is why the gradients look as they should 
until you then break link on the imported version (step 3 from above) and then 
the gradientUnits="userSpaceOnUse" is removed from the defs of the imported 
one, but is then applied to the originally opened one (or at least that is how 
it looks without inspecting too carefully).

Original comment by adrianbj...@gmail.com on 14 Sep 2010 at 3:00

[GoogleCodeExporter]

I know this doesn't affect users from creating all their own images, but with 
2.6 coming with the IAN image library (and maybe others) and the ability to 
open/import svg's that were probably created in Illustrator or Inkscape, it 
seems to me that this should be a higher priority for 2.6.

Original comment by adrianbj...@gmail.com on 28 Sep 2010 at 2:48

[GoogleCodeExporter]

Sure thing, been meaning to look at this.

Original comment by adeve...@gmail.com on 28 Sep 2010 at 3:22

• Added labels: NeededFor-2.6, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Okay, think I've got this fixed...unfortunately I'm getting errors on commit. 
Hopefully can check it in soon.

Original comment by adeve...@gmail.com on 28 Sep 2010 at 6:30

[GoogleCodeExporter]

Quick work - looking forward to testing this :)

Original comment by adrianbj...@gmail.com on 28 Sep 2010 at 6:34

[GoogleCodeExporter]

Okay, give it a shot in r1764. Both open as well as import should work as 
expected.

Original comment by adeve...@gmail.com on 28 Sep 2010 at 7:00

• Changed state: Fixed

[GoogleCodeExporter]

Looks to be working a treat in FF - great work! If I'd know how easy it was, 
I'd have done it myself ;)

Of course the issue remains in webkit browsers because of the weird 
gradientTransform behavior that you mention in Issue 469. Any further thoughts 
on how to tackle that? We have a lot of Mac users these day and therefore many 
Safari users, not to mention the iPad crowd - I have already had a couple of 
complements on how easy it is to create diagrams with our symbols on the iPad, 
so this is definitely going to be an expanding market.

Original comment by adrianbj...@gmail.com on 28 Sep 2010 at 7:22

[GoogleCodeExporter]

Actually that should only be a problem for radialGradients...have you ran into 
(m)any images with those? I do see the bug here in Chrome too now, will look 
into it.

Also, I promise to make iPad compatibility a top priority if you can have one 
sent to me. :)

Original comment by adeve...@gmail.com on 28 Sep 2010 at 7:38

[GoogleCodeExporter]

Yeah, actually I was wondering about that too - I thought it was supposed to 
just be radials, but seems like both Chrome and Safari are still having issues 
with the mangrove flower example (which only has linear gradients).

As for how many images with radial gradients - I just did a search and there 
are 16204 radial gradients across 463 images - so just a few :)

I'll work on the iPad - need my boss to get me one first.

Original comment by adrianbj...@gmail.com on 28 Sep 2010 at 8:03

[GoogleCodeExporter]

Sorry, should have added - here is one of those 463 images with a radial 
gradient - if it helps with testing:
http://ian.umces.edu/imagelibrary/displayimage-4549.html

It is also in the mangrove library - Ceriops australis

Original comment by adrianbj...@gmail.com on 28 Sep 2010 at 8:09

[GoogleCodeExporter]

Looks like webkit has a bug searching for camelCase tags, in this case 
linearGradient and radialGradient. With a workaround, this has been fixed in 
r1765.

Original comment by adeve...@gmail.com on 28 Sep 2010 at 8:23

[GoogleCodeExporter]

Re: radial gradients - D'oh! Okay, thanks, will investigate. :)

Original comment by adeve...@gmail.com on 28 Sep 2010 at 8:26

[GoogleCodeExporter]

Chrome and Safari look perfect now re the linear gradient bug. Thanks for 
looking into the radial gradient issue.

Original comment by adrianbj...@gmail.com on 28 Sep 2010 at 8:41