kimoa / svg-edit

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

Better Importing of rasters #801

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Based on feedback from the Chrome Web App store: 
https://chrome.google.com/webstore/detail/hnbpdiengicdefcjecjbnjnoifekhgdo# it 
is not at all obvious to users upon first glance how to import rasters.

Now that we have the File API, I'm starting to think of a better way to do 
this.  Proposal:

  a) Change "Import SVG" on the main menu to "Import"
  b) The user can choose a SVG, PNG, JPG file from their hard drive
  c) We use the File API to determine what type of image file it is
  d) If it's SVG, use our parser to get the SVG into the document
  e) if it's a raster, turn it into a data: URL and import it into the document via an <image> tag
  f) Get rid of the Image tool on the left

Other than lack of browser support (IE, Opera) are there any problems with this 
approach that I'm missing?

Original issue reported on code.google.com by codedr...@gmail.com on 21 Mar 2011 at 8:50

GoogleCodeExporter commented 9 years ago
Actually we shouldn't get rid of the Image tool because that allows images to 
be imported via URL or relative reference.

I think the majority of people who want to play with the tool will want to pull 
another image into the canvas and play with it and then expect the SVG to be a 
self-contained image (much like a PSD in Photoshop is).  I think this means 
that we should take "Import" to mean "bring this image into the canvas and let 
the SVG be self-contained.  I'll have to think about the interface to continue 
to let images be referenced via non-data URLs.

Original comment by codedr...@gmail.com on 21 Mar 2011 at 9:17

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

Original comment by codedr...@gmail.com on 25 Mar 2011 at 5:20