chenbo007 / svg-edit

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

Load SVG files #60

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
It occurred to me that an editor that can save, but not load, requires you
to do all your editing in one sitting.  This is not as useful as an editor
where you can save, re-load and keep editing.  

This issue covers this missing functionality.

In order to remain client-side, I would suggest the following mechanism:

1) Provide a 'load' button on the top toolbar

2) the Load button would bring up a small dialog that asks for a URL

3) Upon getting the URL, the HTML editor would use XMLHttpRequest to fetch
the URL text contents

4) Upon receiving the SVG text, the editor should use a whitelist approach
to the elements it allows in (for security purposes).  Current whitelist
would be limited to:

  * elements that SVG-edit supports (path, line, rect, ellipse, circle, text)
  * attributes that SVG-edit supports (fill, fill-opacity, stroke,
stroke-opacity, stroke-dasharray, x, y, width, height, cx, cy, r, rx, ry,
opacity, font-size, font-weight, font-style, font-family, id, xmlns)

The reason we do whitelist is because of
[http://www.feedparser.org/docs/html-sanitization.html#advanced.sanitization.why
this article].  We don't want to allow scripts into the editor.  We also
want to make sure our editor reasonably supports the elements in the loaded
SVG.

Combine this with Issue 59 effectively allows you to bring up local or
remote files for editing - a very powerful capability for SVG-edit

Original issue reported on code.google.com by codedr...@gmail.com on 8 Jul 2009 at 1:28

GoogleCodeExporter commented 9 years ago
Issue 32 has been merged into this issue.

Original comment by codedr...@gmail.com on 8 Jul 2009 at 9:01

GoogleCodeExporter commented 9 years ago

Original comment by codedr...@gmail.com on 9 Jul 2009 at 7:58

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Wouldn't loading SVG files with xmlhttprequest constitute a cross domain 
sandbox violation?

Original comment by Antimatter15 on 28 Aug 2009 at 10:23

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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