search

kimoa / svg-edit

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

Saving large files in causes unresponsive script popup in Firefox, prevents saving in Chrome #477

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Open a "complex" SVG
2. Try to Save it
3.

What is the expected output? What do you see instead?
I would prefer to see a save dialog, but even with the current situation of
displaying the final SVG in a new browser window, I get an Unresponsive
Script error in FF 3.6. I have tried continuing several times and it never
seems to get anywhere. If I click Stop, then I get a simplified version of
the SVG - colors messed up and no gradients.

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

Please provide any additional information below.

Original issue reported on code.google.com by adrianbj...@gmail.com on 12 Feb 2010 at 3:27

Attachments:

GoogleCodeExporter commented 8 years ago 
Hm, this is the second bug I'm not able to reproduce related to Unresponsive 
Script
in Firefox 3.6.   See Issue 476.

I can, in fact, open that fish, click Save and see it in a new tab.  The 
gradients
all show up as black, but that's a known Firefox bug.

I assume you're on Windows?

Original comment by codedr...@gmail.com on 12 Feb 2010 at 3:54

GoogleCodeExporter commented 8 years ago 
For the gradients showing as black problem, there's nothing we can really do to 
fix
this since it's a bug in Firefox.  The only thing I've thought of is Issue 438.

Note that if you are going to integrate SVG-edit into a website, you'd replace 
the
default saveHandler to submit the file to a web server for storage, then open 
it in a
new window (not using the data: URI)

Original comment by codedr...@gmail.com on 12 Feb 2010 at 3:57

GoogleCodeExporter commented 8 years ago 
Yep, I am on windows.

As for the FF gradient bug - there must be something I am not understanding 
here,
because I can open that same file directly in FF and it shows perfectly. ie:
http://ian.umces.edu/iil-symbol-fundulus-heteroclitus-male_inkscape.svg

Does the bug only occur when trying to display via data: URI?

Original comment by adrianbj...@gmail.com on 12 Feb 2010 at 4:06

GoogleCodeExporter commented 8 years ago 
I think something is not right in the original file.

The front round fin is supposed to show err... stuff, linear paths. They are 
almost
invisible, even in Inkscape. (the fin appears "plain" and you see the linear 
things
very very very lightly).
If you switch to Outline in Inkscape, you'll see them. Anyway, on these paths 
on all
the fins, I see a strange thing in this file.

These things are filled with url(#ian_symbols_239b95d691760ae4b9d218c06aee0246),
which are (very strange named) gradients.
If you open the Inkscape gradient editor after having selected one of these 
paths,
you'll see that the gradients consist of three stops.
E.g. for the bottom path on the round fin:
it's filled with ian_symbols_b1366066a...
and the gradient editor shows:
stop1566, which is unselectable (why?)
stop1566_dup (same values as stop1566)
stop1558

I have never seen gradients with that sort of name in Inkscape (generated by
Inkscape) and unselectable stops, maybe that's the cause why loading the file 
is slow
(I do not get a "busy script" myself).

Was the file made with Inkscape originally?

Original comment by worms_...@yahoo.com on 12 Feb 2010 at 5:59

GoogleCodeExporter commented 8 years ago 
"Does the bug only occur when trying to display via data: URI?"

Yes, that is exactly the reason.  See Firefox bug
https://bugzilla.mozilla.org/show_bug.cgi?id=308590

Original comment by codedr...@gmail.com on 12 Feb 2010 at 8:29

GoogleCodeExporter commented 8 years ago 
The "stuff" in the front round fin are meant to be there and they actually 
showed up
quite distinctly in the original file - The fin itself is meant to be
semi-transparent, but in the example I uploaded, I set the opacity to "1" to 
deal
with a cairo - svg to pdf bug (see below for more info on this).

The names of the gradients are generated automatically when a user uploads an 
SVG to
our image library. They are simply "ian_symbols" plus a globally unique ID. 
Typically
the illustrations in our library are used to create diagrams of ecosystems so 
people
will be placing several illustrations into the diagram - this is my approach to 
avoid
any possible conflicts with duplicate IDs. I would be curious to hear if anyone 
has
any better ideas.

As for the duplicate stop in the gradient - this is something I have been
experimenting with. I have been trying to use cairo/rsvg-convert to convert the 
SVGs
to PDF. From my testing it seems that cairo can't handle gradients with only two
stops - sometimes it rasterizes the shape and other times it creates some sort 
of
un-editable shape with a clipping mask, although it still seems to scale ok. If 
I
programmatically ensure that every gradient has a least three stops (by 
duplicating
one), then they are always converted properly by cairo. I would also like to 
hear if
anyone has any other ideas on how to better deal with this. The only other thing
cairo can't seem to handle is preserving transparency - I know this is some 
issue
with the PDF format, although I don't fully understand since AI files are PDF 
these
days and they handle transparency just fine. Sorry, I am very off-topic now.

Original comment by adrianbj...@gmail.com on 12 Feb 2010 at 10:51

GoogleCodeExporter commented 8 years ago 
I just noticed another problem when saving large files in Chrome...the image 
appears as expected, but the URL shows as just being "data:" and the "Save Page 
As..." option is disabled! So that's even worse as is prevents saving 
altogether.

Wonder if we can track down what exactly triggers the Firefox Unresponsive 
Script popup, since Chrome and Opera process it within about 2 seconds for me.

Original comment by adeve...@gmail.com on 20 Jul 2010 at 2:43

GoogleCodeExporter commented 8 years ago 
Is there any plan to fix the issue ? it will really help to wikipedians to 
translate svg images to there languages using google transliteration add-ons in 
browser

Original comment by naveenpf on 19 Jun 2011 at 3:04

GoogleCodeExporter commented 8 years ago 
Currently i am able to make only PNG formats. If there is correction we need to 
rework completely.
I dont know any of these languages; even though i could create that image. If 
there are mistakes we need to correct it .

http://commons.wikimedia.org/wiki/File:Kerala-map-sa.png
http://commons.wikimedia.org/wiki/File:Kerala-map-kn.png
http://commons.wikimedia.org/wiki/File:Kerala-map-hi.png

Original comment by naveenpf on 19 Jun 2011 at 3:07

GoogleCodeExporter commented 8 years ago 
In my testing now on trunk, 
http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html ...

1. Chrome still doesn't show the full "data:" URL, but it does allow saving for 
me. Though it does easily become unresponsive, I think that should probably be 
reported to Chrome instead.

2. I am no longer seeing an issue in Firefox (and the mentioned bug is marked 
as fixed).

3. I still am seeing some shading differences, but that should really be 
reported as a new issue, I think.

Can someone confirm? Can we close the issue?

Original comment by bret...@gmail.com on 8 Apr 2014 at 2:10

GoogleCodeExporter commented 8 years ago

Original comment by bret...@gmail.com on 8 Apr 2014 at 2:24