Closed GoogleCodeExporter closed 9 years ago
Issue 32 has been merged into this issue.
Original comment by codedr...@gmail.com
on 8 Jul 2009 at 9:01
Original comment by codedr...@gmail.com
on 9 Jul 2009 at 7:58
The 'white list' was implemented as part of Issue 59.
Another requirement of this feature would be to launch allow the editor to be
launched with a SVG file in a RESTful way. For instance:
http://svg-edit.googlecode.com/.../svg-editor.html?url=http://example.com/foo.sv
g
OR
http://svg-edit.googlecode.com/.../svg-editor.html?src=<svg...
Original comment by codedr...@gmail.com
on 30 Jul 2009 at 1:48
Pushing out to 2.4 when we will support more of the SVG spec (things like <g>
and
<use>). If someone wants to, they can copy any SVG source and paste into the
source
editor, it's just not as likely to work.
Original comment by codedr...@gmail.com
on 17 Aug 2009 at 12:12
Also you could add a <div id="svgdata">%(filecontent)s</div> to the html part
and
fill that from your python script by e.g.
filecontent = file(fpath, 'r').readlines()
filecontent = ''.join(filecontent[1:])
if filecontent:
# svg data is saved as xml. at least firefox changes the data by adding
closing tags e.g. </rect></circle></circle></circle></rect></svg>
# this renders then only the first element
filecontent = "<!-- %s -->" % filecontent
and at svg-edit.js in function svg_edit_setup()
var svg = document.getElementById("svgdata");
var filecontent = svg.innerHTML;
// because moin uses currently HTML 4.0.1 we send the data as a comment in t
he HTML code
filecontent = filecontent.replace('<!-- ', '').replace(' -->', '');
if (filecontent != '') {
if (!svgCanvas.setSvgString(filecontent)) {
if( !confirm('There were parsing errors in your SVG source.\nRevert
back to original SVG source?') ) {
return false;
}
}
svgCanvas.clearSelection();
}
Original comment by rb.p...@gmail.com
on 25 Aug 2009 at 5:41
Wouldn't loading SVG files with xmlhttprequest constitute a cross domain
sandbox violation?
Original comment by Antimatter15
on 28 Aug 2009 at 10:23
Antimatter15 - I think you're right. I guess we have to live with that
limitation as
I have no further ideas.
As discussed on the mailing list - I won't be working on this in 2.4 so pushing
it
out. If someone wants to work on it for 2.4 let me know.
Original comment by codedr...@gmail.com
on 8 Oct 2009 at 5:06
I think with the patch in Issue 392 would be enough for me to resolve this
issue in 2.5
Original comment by codedr...@gmail.com
on 9 Jan 2010 at 10:53
Another idea would be to use window.localStorage to store files in the browser.
That way at least you could
start a document, save it, and then load it up later.
You could also do autosaves into local storage to recover from accidentally
crashing or closing a tab or
window.
Another idea would be to come up with a file loading api, (it'd have to be on
the same server for use with
Ajax). Something so I could write a ruby backend for for storing svg files
(maybe in svn or git) and then svg-
edit basically needs three commands:
list -- to get the list of documents
load -- to get a specific document
save -- to save a specific document
Original comment by bam.tho...@gmail.com
on 12 Jan 2010 at 8:38
It is now possible to open documents in browsers that support the File API
(Firefox
3.6) as of r1196, so closing this issue. Let's hope more browsers support this
capability soon!
Original comment by codedr...@gmail.com
on 13 Jan 2010 at 8:58
Original issue reported on code.google.com by
codedr...@gmail.com
on 8 Jul 2009 at 1:28