rebootcode / svg-edit

Automatically exported from code.google.com/p/svg-edit
MIT License
0 stars 0 forks source link

Open/import image containing <symbol> in defs results in no gradient in FF and no image displayed in Chrome #700

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Open or import an image containing a symbol def:
http://ian.umces.edu/diagrammer/editor/svg-editor.html?url=/imagelibrary/albums/
userpics/12789/iil-symbol-ruppia-maritima-fruits.svg

or Flora>Seagrass/SAV>Ruppia maritima fruits

What is the expected output? What do you see instead?
Should load image, but nothing happens except for a firebug error:
 [Exception... "Node cannot be inserted at the specified point in the hierarchy" code: "3" nsresult: "0x80530003 (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR)" location: "http://ian.umces.edu/diagrammer/editor/svgcanvas.js Line: 2573"] { constructor=DOMException,  code=3,  more...}

Please use labels and text to provide additional information.

Ideally I wanted to have all the images in our library free of <symbol>, but 
the people uploading made some mistakes and 300+ images made it in still with 
<symbol>. In some ways it makes sense to keep the def if used for repetitive 
elements, but in this case it is just one symbol def for the entire image.

Original issue reported on code.google.com by adrianbj...@gmail.com on 1 Oct 2010 at 6:01

GoogleCodeExporter commented 9 years ago
I can fix the bug, but there'll still be the no-gradient issue until the link 
is broken...would it make sense to convert symbol->svg on import for Firefox?

Original comment by adeve...@gmail.com on 1 Oct 2010 at 7:39

GoogleCodeExporter commented 9 years ago
Also that particular file didn't appear to work anywhere due to a missing 
xmlns:xlink="http://www.w3.org/1999/xlink" in the root SVG...

Original comment by adeve...@gmail.com on 1 Oct 2010 at 7:40

GoogleCodeExporter commented 9 years ago
I think it would make send to convert symbol->svg and maybe not just for FF 
since someone may import it into svgedit in a non-FF, save to their HDD and 
then open the SVG directly FF (not through svgedit). I don't know - the other 
alternative is just for FF and then perhaps the default behavior when saving as 
SVG could be to convert svg->symbol. It wouldn't take care of direct viewing in 
FF, but would allow for much better (not perfect) results in Illustrator and 
still be ok if they opened again in svgedit in FF.

Does that make sense, or did I just go around in circles ;)

Original comment by adrianbj...@gmail.com on 1 Oct 2010 at 7:53

GoogleCodeExporter commented 9 years ago
I just downloaded from the library itself and it works fine in Illustrator and 
has the xmlns:xlink

http://ian.umces.edu/imagelibrary/displayimage-4694.html

Does that work for you?

Original comment by adrianbj...@gmail.com on 1 Oct 2010 at 7:54

GoogleCodeExporter commented 9 years ago
Sorry, you are right, there is no xlink declaration, but it does still open in 
Illustrator ok

Original comment by adrianbj...@gmail.com on 1 Oct 2010 at 7:58

GoogleCodeExporter commented 9 years ago
You know...there is a solution that I'd dismissed before for its potential for 
leading to other problems, but thinking about it more it really might not be so 
bad.

Symbols with gradients CAN work in Firefox...just as long as all the gradients 
are directly under the <defs> and not inside the symbol. The concern there of 
course is that it's less clear (when looking at the source) which gradient 
belongs to which symbol, and so it's less obvious whether the gradient should 
be deleted with a symbol, if it's deleted.

But...we could certainly try this (maybe just for FF), and see whether or not 
that would actually lead to problems. So I think I'll first give that a shot 
(next week, probably).

Original comment by adeve...@gmail.com on 1 Oct 2010 at 8:18

GoogleCodeExporter commented 9 years ago
I have added the xlink dec and it certainly loads fine now - my regex during 
upload to the library will now take care of this for all future images - now I 
just need to update all the existing ones.

Also, Chrome is not showing the image at all - just an empty and unscaled 
bounding box.

I have changed the summary to reflect the real issue - hope that is not too 
confusing.

Original comment by adrianbj...@gmail.com on 1 Oct 2010 at 8:33

GoogleCodeExporter commented 9 years ago
Interesting thoughts on placing the gradients directly under the <defs>. As 
well as the issues for svgedit (which I am sure you can code to overcome), I 
wonder what impact it will have in illustrator/inkscape when someone goes to 
break link to symbol or delete a symbol - just another possible problem to 
think about :)

Would be nice if it was workable though!

Original comment by adrianbj...@gmail.com on 1 Oct 2010 at 8:37

GoogleCodeExporter commented 9 years ago
So trying that in r1774, works okay in FF for this example. Note that breaking 
the link of the final symbol causes the new group to shift in this case, 
because the symbol has a viewBox set. Shouldn't be terribly hard to fix, just 
something I wasn't expecting to see. :)

Looking into the Chrome bug now.

Original comment by adeve...@gmail.com on 4 Oct 2010 at 5:16

GoogleCodeExporter commented 9 years ago
Apparently the viewBox is what's causing Chrome to freak out...ugh.

Original comment by adeve...@gmail.com on 4 Oct 2010 at 5:55

GoogleCodeExporter commented 9 years ago
Thanks for all your efforts on this (and all the other cool things you have 
been working on) and sorry for the day of silence - I am run off my feet at the 
moment. Testing the trunk I can't get the Ruppia fruit to load at all in FF or 
Chrome via image library import or open. Sorry for the lack of further info. I 
think I am going to go through and "fix" all our images with a symbol wrapper. 
Of course I think that svg-edit still needs to be able to handle these 
regardless.

Original comment by adrianbj...@gmail.com on 5 Oct 2010 at 9:12

GoogleCodeExporter commented 9 years ago
Strange...both import and open work fine in Firefox for me.

Original comment by adeve...@gmail.com on 6 Oct 2010 at 4:34

GoogleCodeExporter commented 9 years ago
That is weird indeed - I finally got around to rebooting my computer and it is 
certainly working fine now. I had tested several times before with browser 
restarts, cache clearing etc and no dice. Anyway, looks good - thanks :)

Original comment by adrianbj...@gmail.com on 7 Oct 2010 at 12:44

GoogleCodeExporter commented 9 years ago
Oops - I think there is a nasty side effect - images without <symbol> are 
"importing" all black in FF, but, they are "opening" ok. I just tested the 
usual crab and duck examples. BUT, fine in Chrome!

Original comment by adrianbj...@gmail.com on 7 Oct 2010 at 12:50

GoogleCodeExporter commented 9 years ago
Fixed in r1780. I also tried opening one of these gradient-outside-symbol files 
into Illustrator to see what would happen...the file opens just fine, and when 
you save it again it stuffs the gradient element back into its symbol. :)

Original comment by adeve...@gmail.com on 7 Oct 2010 at 5:43

GoogleCodeExporter commented 9 years ago
Just noticed that when saving with FF 4 without the server save extension, the 
symbols don't appear in the browser for me. Save Page As does result in a valid 
svg though, so it seems that the <symbol> element is still having issues in FF. 
Maybe resort to the webkit approach of copy/paste save?

Original comment by adrianbj...@gmail.com on 10 Oct 2010 at 11:04

GoogleCodeExporter commented 9 years ago
Sounds to me like the usual FF problem where anything defined in the defs (like 
gradients) don't show up in data URLs. Should be a warning message about that 
the first time you save.

Original comment by adeve...@gmail.com on 11 Oct 2010 at 2:42

GoogleCodeExporter commented 9 years ago
I am thinking that this can probably be closed, although perhaps the saving 
issue in FF still needs to be addressed. I just wanted to make a note here 
though that the Ruppia maritima example file mentioned in the initial report no 
longer has a <symbol> element, in fact I have cleaned up all the symbol 
elements from all the images in the IAN library. Probably wasn't necessary, but 
just wanted to simplify things as much as possible.

Original comment by adrianbj...@gmail.com on 12 Oct 2010 at 9:33

GoogleCodeExporter commented 9 years ago
Closing as suggested.

Original comment by adeve...@gmail.com on 12 Jan 2011 at 3:25