rebootcode / svg-edit

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

svg-viewer.html, svg-viewer.js (embeddable) #538

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
as adeveria suggested, i will open an issue on this one:

Using svg-edit i often felt the need to just have a viewer interface :

+ with: background, zoom, open source text, open/save file, layers 
- but without: other buttons, tools, content modifiers

I guess that is just a question of having another interface, svg-viewer.html 
that uses parts of 
svgcanvas.js functions and yet a second viewer embeddable into any web page 
(without layers, 
etc), in .js and .css, for presenting a svg string into that page, with a link 
to edit that svg string 
inside 
http://svg-edit.googlecode.com/svn/branches/2.4/editor/svg-editor.html 

I believe having this available to web designers would help a lot the 
visibility of the project to web 
designers AND end-users.

Original issue reported on code.google.com by Christia...@gmail.com on 14 Apr 2010 at 7:23

GoogleCodeExporter commented 8 years ago
What's the point of saving in a viewer?

What could you do in layers in the viewer?  Just make them visible/invisible?

Just wondering why bringing up the SVG image in a browser isn't good enough.

Original comment by codedr...@gmail.com on 14 Apr 2010 at 7:48

GoogleCodeExporter commented 8 years ago

Original comment by codedr...@gmail.com on 14 Apr 2010 at 7:49

GoogleCodeExporter commented 8 years ago
Ok, pan/zoom I can see.  But this sounds like a side-project to me (or a fork or
something).

Original comment by codedr...@gmail.com on 14 Apr 2010 at 7:49

GoogleCodeExporter commented 8 years ago
it's not really a fork.. any change in svgcanvas.js will influence both 
svg-editor.html and svg-viewer.html/.js 

yes.. pan, zoom are very important
but also the layers view/hide

could this be common code between svg-editor.html and svg-viewer.html? so 
changing one would change both?

Original comment by Christia...@gmail.com on 14 Apr 2010 at 7:55

GoogleCodeExporter commented 8 years ago
then.. another way of looking at this: make all tools that are SVG content 
modifiers as extensions and we remain 
with the basic viewing tools as "core"

Original comment by Christia...@gmail.com on 15 Apr 2010 at 4:00

GoogleCodeExporter commented 8 years ago
browsing the issues, i noticed that this is very akin to issue 188, but my idea 
was to leave svg-edit in place. 
so the process of working with svg-edit would be like this:

1. a normal webpage with site content will load only svg-view and the svg data 
to be presented (or some 
custom blank data)
2. if the user wishes, can edit this content at the click of the button: he 
will be directed together with the svg 
data to svg-edit full
3. when user saves: the data will be saved on the site or on the local computer 
(as user wishes) and the initial 
page is presented with svg-view (eventually with all the changes made in 
svg-edit)

Original comment by Christia...@gmail.com on 19 Apr 2010 at 4:05