Launch SVG-edit with a specific file in the URL

[GoogleCodeExporter]

When the editor has the function of a pop-up window from a web form, it
needs a way of loading the data form a chosen field of that form and in the
end, save to it. maybe have a new "pop-up .html" file that accommodates
this behavior seamlessly. After this is done, we can start proposing to
many CMS systems to include our editor. (bump it's importance to Critical)

Original issue reported on code.google.com by Christia...@gmail.com on 9 Jul 2009 at 7:52

[GoogleCodeExporter]

Can you clarify what you mean by 'chosen field of that form' - what would be 
loaded
in, a given SVG file?  I think this is covered somewhat by other bugs.

Original comment by codedr...@gmail.com on 9 Jul 2009 at 2:31

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

For example, Issue 59 and Issue 60 cover how to load the editor with SVG text.  
This
would satisfy the first part of what you're talking about.  The second part
(exporting the SVG back) would be somewhat covered by the data: base64-encoded 
SVG we
spit back - just need to allow that to be hooked up somehow...

Original comment by codedr...@gmail.com on 9 Jul 2009 at 2:36

[GoogleCodeExporter]

ok.. let me offer you an example: http://www.dynarch.com/projects/calendar/

in the middle of the page is a demo of a form (with a single field) that has a 
button
that opens a pop-up with a small application that you can use to fill-in that
specific field.
of course in our case the field will be hidden and (maybe) close to the
trigger-button we will display the current SVG image (maybe with websvg flash)
the svg-edit canvas opened in this fashion has to know from which field to load 
it's
data and to which field of the form to save it (and we should leave the freedom 
to
the developer to choose a different form-field)

Original comment by Christia...@gmail.com on 9 Jul 2009 at 3:13

[GoogleCodeExporter]

Ok, I understand.  We will use this issue to track launching svg-edit with a 
specific
URL, probably using a URL arg.  Something like:

http://svg-edit.googlecode.com/svn/tags/stable/editor/svg-editor.html?url=foo.sv
g

Original comment by codedr...@gmail.com on 9 Jul 2009 at 5:48

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by codedr...@gmail.com on 27 Jan 2010 at 9:30

• Changed title: Launch SVG-edit with a specific file in the URL

[GoogleCodeExporter]

Ok, I think this is taken care of in r1296.

http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html?url=images/logo.
svg

Original comment by codedr...@gmail.com on 29 Jan 2010 at 5:54

• Changed state: Fixed
• Added labels: NeededFor-2.5

[GoogleCodeExporter]

yes!

a more interesting test is:

http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html?url=http://svg-
edit.googlecode.com/svn/trunk/editor/images/logo.svg

and works. beautiful.

Original comment by Christia...@gmail.com on 29 Jan 2010 at 10:58

[GoogleCodeExporter]

any chance for another input variable: a background?

url= a SVG file
bg= a PNG/JPG/GIF file

an example link:

http://svg-edit.googlecode.com/svn/trunk/editor/svg-editor.html?
url=images/logo.svg&bg=images/logo.png

Original comment by Christia...@gmail.com on 29 Jan 2010 at 11:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This works nicely except that something is happening to the gradients as soon 
as you
want to edit the file (in the example logo.svg).

The screenshot attached shows the file as it is right after importing on the 
left,
and on the right, after "fit to content" in Firefox 3.7: the gradients have 
changed
or disappeared. 
In addition, in Opera, I get many Javascript warnings after ungrouping the 
pencil
(see Issue 422 ) and the biggest shape with the yellow gradient moves all by 
itself
around the canvas. 

Original comment by worms_...@yahoo.com on 29 Jan 2010 at 12:17

Attachments:

• capture_logo.jpg

[GoogleCodeExporter]

Hi Wormsxulla, thanks for catching this, it is a general problem with the way we
handle transforms and gradients. I can explain the problem like this:

  * create a fill gradient from top to bottom (the default one will do)
  * draw a rect with the gradient
  * grab the bottom border of the rect and resize it upwards in the negative
direction until it has been flipped vertically, notice the gradient is also now
flipped (yellow in the top-right)
  * release the mouse, notice the gradient changes back to the original one (yellow
in the bottom-right)

Would you mind opening up a bug about it?

Original comment by codedr...@gmail.com on 29 Jan 2010 at 12:42

[GoogleCodeExporter]

OK.

I also noticed that when doing that, the <defs> are created below the shape 
itself,
and that we also have lost the <!-- Created with the awesome SVG-edit webapp -->
comment, I wonder since when!

Original comment by worms_...@yahoo.com on 29 Jan 2010 at 12:52