Closed GoogleCodeExporter closed 9 years ago
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
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:
Issue 644 has been merged into this issue.
Original comment by adeve...@gmail.com
on 9 Sep 2010 at 1:33
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
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
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
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
Sure thing, been meaning to look at this.
Original comment by adeve...@gmail.com
on 28 Sep 2010 at 3:22
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
Quick work - looking forward to testing this :)
Original comment by adrianbj...@gmail.com
on 28 Sep 2010 at 6:34
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
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
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
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
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
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
Re: radial gradients - D'oh! Okay, thanks, will investigate. :)
Original comment by adeve...@gmail.com
on 28 Sep 2010 at 8:26
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
Original issue reported on code.google.com by
adrianbj...@gmail.com
on 23 Jul 2010 at 5:40