Ability to add clipart to drawing

[GoogleCodeExporter]

an optional button to a directory with categorized SVG in sub-directories.
SVGs that may be used to load additional objects to the canvas. this button
should not be visible in the normal editor. it should be displayed only for
instances of the editor that request it at creation-time. I can program the
pop-up for the PHP/JS setup.

Original issue reported on code.google.com by Christia...@gmail.com on 10 Jul 2009 at 11:30

• Blocked on: #72, #310

[GoogleCodeExporter]

Yeah, I think that right now most users will want an SVG they know will look 
the same in all browsers...I guess once FF fixes that bug we use <symbol> 
instead.

Original comment by adeve...@gmail.com on 28 Jul 2010 at 8:42

[GoogleCodeExporter]

Just checked out the new break link button - seems great. The only thing I 
would like to see is to have the label (title) displayed in the context menu 
while it is still a reference element. Maybe there is a logical reason for not 
having this?

Original comment by adrianbj...@gmail.com on 29 Jul 2010 at 3:21

[GoogleCodeExporter]

Nope, just a bug that's been fixed now. :)

However, I'm wondering if I should leave it editable (I think it currently 
doesn't actually work)...Would the user expect it to change on all instances or 
just that one? Probably the latter. So I think I'll disable it for now, then 
later we can find a way to let users edit "master/template/symbol" elements 
directly.

Original comment by adeve...@gmail.com on 29 Jul 2010 at 3:25

[GoogleCodeExporter]

Seems like there is a new bug in Chrome - imported images (via image library) 
are not reduced in size and when you click the break link button, they are no 
longer visible.

Original comment by adrianbj...@gmail.com on 29 Jul 2010 at 3:39

[GoogleCodeExporter]

Ugh, spent about forever tracking down that bug...and it turns out the only 
problem was forgetting to give the <use> an ID. Fixed in r1651.

Original comment by adeve...@gmail.com on 29 Jul 2010 at 5:50

[GoogleCodeExporter]

So what's left for this issue? The following come to my mind:

- Nicer icon. Christian's is very nice, but I'd like to keep all our icons as 
made by SVG-edit. 

- Have imported raster images go into the <defs> too, this makes a lot of sense 
since copies of data URLs will likely make the SVG file size get huge.

- Offer open/import radio buttons on the library window to allow both options.

- Set up a proper looking library to include ourselves. This will require 
getting more images as well as making a better UI.

- Contact OCAL or perhaps others to see if they're interested in setting up a 
compatible library.

- Test undo/redo functionality, I may not have done this enough.

Original comment by adeve...@gmail.com on 29 Jul 2010 at 8:04

[GoogleCodeExporter]

Just a few extra thoughts:

- I think there needs to be different icons for the shape library vs the image 
library.
- Should the image library and shape library share a spot on the main left 
toolbar (like for eg the 3 rectangle tools)? It would be one less click to get 
to the image libraries for repeated importing.
- Personally I like the iframe option for the flexibility it gives me for 
controlling how our IAN images are searched and served up and I wouldn't want 
to lose this, but I still wonder if the JSON or XML approach might ALSO be 
needed if you are to get other libraries like OCAL on board.
- I have just implemented a lightbox/custom palette within the IAN library 
interface and users can create/edit this through links below each image - an 
ajax call updates our database to make this as seamless as possible. I hope 
this will be useful for users so that they can build a palette (lightbox) of 
images they use regularly. I think this could also be handy to simplify things 
in an educational environment. I wonder if there could be a way to do this with 
other image libraries as they are added - maybe a cookie approach handled by 
svg-edit.

Original comment by adrianbj...@gmail.com on 30 Jul 2010 at 12:13

[GoogleCodeExporter]

Just had another thought - I wonder if it might be possible to provide a 
modified link so that users could insert multiple images without being taken 
back to the svg-edit canvas and having to open up image library each time. What 
I am envisioning is the ability to have the images imported in the background 
and then once the user is finished importing, they close the image library 
window and all the images are on the canvas and ready to use. This could really 
speed up the process of creating diagrams - definitely very useful for my 
user's purposes - hopefully for others as well.

Original comment by adrianbj...@gmail.com on 30 Jul 2010 at 12:31

[GoogleCodeExporter]

If I understand you correctly, this seems to be similar to the concept of a 
'stage' that we've discussed before but it seems like it was not made into an 
issue.  Feel free to raise another one.  My own preference is to keep bugs 
smaller in scope and this one is already pretty large with a long history :)

Original comment by codedr...@gmail.com on 30 Jul 2010 at 12:35

[GoogleCodeExporter]

Not sure if it would be considered a stage or not. I guess I would liken it 
more to a panel. Basically I am thinking it wouldn't change much from the 
current look accept that it wouldn't close by default when a user clicks on an 
image, although I think it would be important to provide some feedback to let 
them now that their choice was in fact imported onto the canvas.

Original comment by adrianbj...@gmail.com on 5 Aug 2010 at 3:27

[GoogleCodeExporter]

Back to the inclusion of raster images from the IAN library - I have added 
these to the interface and given users the option to browse (or search) vector 
only (default), raster only, or both. Would you mind changing the text 
describing the IAN library to:

Integration and Application Network (IAN) Image Library 
(ian.umces.edu/imagelibrary/)
Free library of 5000+ free vector illustrations, photos, satellite image and 
maps.

Thanks,
Adrian

Original comment by adrianbj...@gmail.com on 5 Aug 2010 at 3:39

[GoogleCodeExporter]

Just discovered that Export to PNG doesn't work unless you click the "Break 
link to reference element" button. Not sure whethet svg-edit should handle 
breaking these before invoking canvg, or whether this is something that canvg 
should be able to handle. 

Feel free to make this a new issue if you want, but since it relates directly 
to image library imports, I thought it best to post here.

Original comment by adrianbj...@gmail.com on 12 Aug 2010 at 8:13

[GoogleCodeExporter]

Just a little extra info on this latest issue - the firebug error if I try to 
export without breaking link is:

"too much recursion  </label> "

Original comment by adrianbj...@gmail.com on 14 Aug 2010 at 6:37

[GoogleCodeExporter]

Again, not sure if this should be another issue or not, but when you delete an 
image inserted via an image library, it only removes the <use> for that 
instance, the <def> for it remains. This makes sense if there are multiple 
instances of the image, but I think the <def> should be removed when the last 
<use> is deleted, otherwise the file is just unnecessarily bloated.

Original comment by adrianbj...@gmail.com on 14 Aug 2010 at 7:11

[GoogleCodeExporter]

#58: Sounds like a good idea, yes.

#62: Yup, sounds like a canvg bug. Might indeed be able to write a workaround 
for it, but would rather spend time on something else.

#64: Indeed, will take care of that.

Original comment by adeve...@gmail.com on 16 Aug 2010 at 3:43

[GoogleCodeExporter]

Thanks for all the responses, enhancements and fixes to come :)

#61: Any chance you could change the details for the IAN Image Library - feel 
free to leave off the "5000+" - that way it should be fine as a description for 
the long term. Also, I obviously doubled up on "free", so the second one can go.

#62: I have submitted bug report to CanVG 
(http://code.google.com/p/canvg/issues/detail?id=57)

Original comment by adrianbj...@gmail.com on 16 Aug 2010 at 4:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Just noticed that imported SVGs from the image library have their metadata 
"condensed". I am not too concerned about this, but there is some loss of 
appropriate spaces etc that might be nice to fix up. I also added a low 
priority feature request for a metadata viewer that might affect this issue: 
Issue 648

Original comment by adrianbj...@gmail.com on 17 Aug 2010 at 5:34

[GoogleCodeExporter]

#62 has been taken care of by r75 of CanVG

Original comment by adrianbj...@gmail.com on 17 Aug 2010 at 5:58

[GoogleCodeExporter]

Not sure when, but #64 was taken care of...can you confirm?

Original comment by adeve...@gmail.com on 31 Aug 2010 at 6:28

[GoogleCodeExporter]

Umm - <def> still remains for me. I thought maybe the order of deletion might 
be a factor, but I tested with the smiley.svg and did a copy and paste and 
deleted both one at a time. Doesn't matter which is deleted first, the <def> is 
still there. 

This is a different bug, but I just inserted the smiley twice from the image 
library and deleted both - now the smiley is defined three times in the <def> :)

Original comment by adrianbj...@gmail.com on 31 Aug 2010 at 6:42

[GoogleCodeExporter]

Ah, I was only testing on raster images, I'm a moron. :) Alright, will go fix, 
hopefully that new bug too.

Original comment by adeve...@gmail.com on 31 Aug 2010 at 6:46

[GoogleCodeExporter]

Alright, the ability to import multiple images in one go (as mentioned in 
comment #58) is now available in r1724! You'll need to select "import multiple" 
in the new dropdown list for this to work. 

Still a bit rough around the edges, I'd like to include a preview of the image 
rather than just the title as happens now...should be easy for raster images, 
but for SVGs it'll get tough as we run into the problem of clashing IDs. One 
way to solve this is to use <img> elements, but of course that's not supported 
in FF until FF4. Alternatively we could have the library owner also send 
through a URL to the preview image, but I wouldn't want to make that a 
requirement.

I've also added a "Open for editing" option, which will simply open an SVG 
instead of importing it.

Thoughts?

Original comment by adeve...@gmail.com on 16 Sep 2010 at 8:18

[GoogleCodeExporter]

This is really cool functionality. Obviously the thumbnail previews would be 
ideal. Not sure what to suggest as the best way to do this. I assume it would 
be too slow to call CanVG to make a PNG? As for having the library owner supply 
a preview image - I would think that most vector libraries would currently have 
a preview png already generated, but maybe down the road these won't be so 
common as the <img> element for SVG becomes commonly supported.

I am not sure that the "Open for editing" label is particularly descriptive 
about its functionality, but I also can't come up with anything better. Maybe 
"Open single (clears canvas)" or "Open single (new canvas)" or something like 
that? If course none of these let the user know that it will come in without 
being a "symbol", but most wouldn't understand the implications and they 
shouldn't need to.

Original comment by adrianbj...@gmail.com on 17 Sep 2010 at 3:22

[GoogleCodeExporter]

Alright, added some more functionality in r1727, see 
extensions/imagelib/index.html for example. 

Your library as it exists currently works largely as it has been, but combined 
with the latest update you improve the behavior by sending metadata about the 
image first.

Once the user clicks, you'll want to first do this:
var my_id = "my_image.svg"; // (some ID unique to this image, could be full URL)
var meta_str = JSON.stringify({
    name: "Fancy image name here", // Optional
    id: my_id,
    preview_url: "http://url-to-preview-image-here" // Optional
});
window.top.postMessage(meta_str, "*");

Then when sending the actual data, do this:
window.top.postMessage('|' + my_id + '|' + data, "*");

Now the extension will know it should show a "Retrieving data" message while 
waiting for the image to download.

Currently the preview image will appear only for raster images, still need to 
do it for SVG data. If preview_url is left out for raster images, the actual 
image (based on the data sent) is used once the transfer is complete.

Hope that's not too confusing, let me know if you have questions. :)

Original comment by adeve...@gmail.com on 17 Sep 2010 at 5:27

[GoogleCodeExporter]

Also note that the ID is not actually visible to the user, it's simply used to 
know which field to update in the preview section once the transfer is complete.

Original comment by adeve...@gmail.com on 17 Sep 2010 at 5:29

[GoogleCodeExporter]

Sweet - I have implemented thumbnails in the multiple import panel for both our 
vector and raster images. Seems to be working great!

Let me know if you think I can optimize anything in particular.

Original comment by adrianbj...@gmail.com on 17 Sep 2010 at 7:13

[GoogleCodeExporter]

Ooh, very cool, works just as I'd hoped! :) 

Re c#75 - I think you're right about the existing PNG availability, and I think 
just showing the given name is an acceptable alternative. 

Yeah, wasn't too happy with "Open for editing" either...maybe "Open as new 
document"?

Anyway, I think it's about time I close this issue now, if for no other reason 
than to prevent this crazy long comment list from getting any longer. :) Not 
sure how important it is that we include our own clip-art library, if it is 
that can be its own issue.

Original comment by adeve...@gmail.com on 17 Sep 2010 at 7:58

• Changed state: Fixed

[GoogleCodeExporter]

I think "Open as new document" sounds better for sure.

Original comment by adrianbj...@gmail.com on 17 Sep 2010 at 8:32