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]

button proposal

Original comment by Christia...@gmail.com on 11 Jul 2009 at 12:14

Attachments:

• library.svg

[GoogleCodeExporter]

Yep, I've been thinking of the clipart feature for awhile and forgot to raise a 
bug.
 Thanks.

Original comment by codedr...@gmail.com on 11 Jul 2009 at 1:20

• Changed title: Ability to add clipart to drawing
• Added labels: NeededFor-Future, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Thoughts on the work items for this issue:

 * UI work (enable new button in interface)
 * enable <svg> and <image> elements embeddable within the root <svg>
 * develop a simple clipart 'browser' window where user can scroll through all
SVG/PNG files in a configured directory and click one
 * import of clipart image into the SVG canvas
 * determine how to serialize the raster images
 * determine the effect of resizing on clipart images
 * testing cross-browser

Original comment by codedr...@gmail.com on 7 Aug 2009 at 2:26

[GoogleCodeExporter]

Issue 156 has been merged into this issue.

Original comment by codedr...@gmail.com on 1 Sep 2009 at 3:37

[GoogleCodeExporter]

Original comment by codedr...@gmail.com on 26 Oct 2009 at 3:55

• Added labels: NeededFor-2.5
• Removed labels: NeededFor-Future

[GoogleCodeExporter]

Original comment by codedr...@gmail.com on 26 Oct 2009 at 4:06

[GoogleCodeExporter]

Original comment by codedr...@gmail.com on 18 Dec 2009 at 7:56

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by codedr...@gmail.com on 9 Jan 2010 at 11:08

[GoogleCodeExporter]

I'd just like to add my support for this feature and suggest that perhaps 
rather than
pointing to a directory with categorized sub-directories, the categorization 
could be
taken from data in a JSON or XML file loaded by SVG-Edit. That way developers 
can
better control what shows up where and can be implemented by any server-side 
language.

As far as implementation goes, I would personally love to see something that 
emulates
Illustrator's Symbol Libraries functionality with separate libraries/palettes 
for
each category. Ideally offering thumbnail views, although I would wonder if this
would slow things down too much (if each library had a lot of images), unless 
it was
a requirement that thumbnails were generated in PNG format server-side and 
cached,
ready for SVG-Edit to display in clipart/library selection palettes.

Original comment by adrianbj...@gmail.com on 12 Feb 2010 at 2:58

[GoogleCodeExporter]

Just a quick thought on this feature. I know you guys have lots of other things 
to
do, so wondering if maybe a quicker solution for the short term might be to 
have a
"Place" option under the main drop down menu. This would still require 
development of
the ability to make <svg> and <image> elements embeddable within the root 
<svg>, but
would hopefully be quicker since there wouldn't be the need to offer all the 
other
features of a full clipart browser. It would be nice to be able to Place via 
file
upload or URI.

Original comment by adrianbj...@gmail.com on 20 Feb 2010 at 12:16

[GoogleCodeExporter]

adrianjones: can you clarify further what you're proposing (i.e. more details, 
an
example or two)?

Original comment by codedr...@gmail.com on 20 Feb 2010 at 6:06

[GoogleCodeExporter]

codedread: I was thinking that this would be a useful feature in its own right, 
as
well as a precursor to the clipart library functionality. The basic idea is 
that the
user can import more than one SVG file onto the SVG-Edit canvas. That way they 
can
build up an illustration consisting of several separate SVG files that they 
already
have either on their hard drive, or by importing one from a URI.

At the moment when you "Open Image" it clears the canvas and loads the image 
onto a
new canvas. What I am proposing is an Import/Place Image that would add the new 
image
onto the existing canvas, along with any other objects that are already present.

Does that clarify sufficiently?

Thanks

Original comment by adrianbj...@gmail.com on 20 Feb 2010 at 6:58

[GoogleCodeExporter]

Ah, indeed.  What you're after is Issue 72.  Which is the first step towards 
clipart
(and as you can see, Issue 71 is blocked on Issue 72).

I just didn't understand "Place" vs. "Import".

Suggest you star both issues :)

Original comment by codedr...@gmail.com on 20 Feb 2010 at 7:00

[GoogleCodeExporter]

Oh, I am sorry - I even posted some thoughts about IDs in Issue 72. Sorry, 
obviously
forgot about that when I made my post here earlier today :)

Original comment by adrianbj...@gmail.com on 20 Feb 2010 at 7:08

[GoogleCodeExporter]

I just discovered "Lovely Charts" (http://my.lovelycharts.com/) a flash based 
diagram
creator. It is actually quite slick and they have a very nice setup for their 
library
functionality that I thought might be worth looking at for some ideas. Other 
features
such as mouse-wheel zoom and hold-space to pan would also be great additions to
svgedit. They have a free registration for the basic version.

Original comment by adrianbj...@gmail.com on 25 Feb 2010 at 10:14

[GoogleCodeExporter]

I don't think I'm going to be able to get to this in the 2.5 timeframe as it 
seems
like a significant chunk of UI.  At least with the ability to import images in
Firefox 3.6+ (and soon WebKit) you can manually do this.

Original comment by codedr...@gmail.com on 6 Apr 2010 at 1:45

• Added labels: NeededFor-2.6
• Removed labels: NeededFor-2.5

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'd like to continue discussion on this feature since we'd like it for 2.6 and 
it's a bit similar to the recently started issue 541 (path library).

I have the following things in mind with this issue based on the above 
comments, feel free to argue with/discuss them:

- Unlike the path objects, each clip-art object should be either its own <svg> 
element or an <image> element.

- When scaled, these clip-art objects should probably just be scaled without 
recalculation, so the clip-art is more likely to appear as intended. 

- For the UI we can either go with something very similar to the one for the 
path library, or we can have an option in the main menu that brings up the 
clip-art picker. I think it's safe to presume that generally clip-art will be 
picked on an image-by-image basis, so the menu option probably makes more 
sense. 

While we can't do directory file listing client-side, we can set up a basic 
category tree again, with another extension offering server-based options.

- For the preview files: 24x24 pngs? Would those be large enough? For the SVG 
previews we could obviously just use the SVG data, assuming the SVGs are 
relatively small. If they're not (say > 250K), then a PNG thumbnail would make 
more sense. I suppose requiring PNG thumbnails on all images would be safer 
based on the variable sizes of clip-art people may want to use...

If anyone would like to start making/gathering free clip-art, that would be 
helpful in getting this started.

Original comment by adeve...@gmail.com on 13 Jul 2010 at 1:21

[GoogleCodeExporter]

I would love to see a way to make collections available from a variety of 
sources to SVGEdit users. For example, we have a collection of 2300 SVG 
illustrations in 56 albums in 6 categories (eg 
http://ian.umces.edu/imagelibrary/thumbnails-77.html) in our free image 
library. Even though these are available under a CC license we do require users 
to register for downloading. I am planning on hosting SVGEdit on our server to 
allow our users to access these illustrations through the clipart feature. I am 
also actually wanting to develop a backend to make SVGEdit into a collaborative 
diagramming tool. But my main point here is that I think it would be great to 
be able to offer our library of clipart to users of any SVGEdit installation. 
To that end, could a list of clipart libraries be maintained and available from 
the UI of SVGEdit? As I mentioned in a previous post, maybe there would need to 
be some JSON/XML schema to handle categorization, names, descriptions, author 
credit, source, details of the SVG path and maybe PNG preview path. I wonder if 
there might also be some kind of token system to validate users trying to 
access resources that require registration?

Any thoughts?

Original comment by adrianbj...@gmail.com on 13 Jul 2010 at 2:20

[GoogleCodeExporter]

That certainly sounds like a good idea...it would probably make sense to look 
at AJAX file browsing libraries so we don't re-invent the wheel.

What do you feel the SVG-edit team should focus on to make this work for you, 
keeping in mind that we'd prefer a solution that works interoperably with other 
libraries? I'm thinking that for now managing the file browsing should be done 
on the library's side (perhaps using an iframe), resulting in a final data URL 
to be fed to the editor. Will think about that a little more...

For the Google Code hosted version of SVG-edit we don't have server abilities, 
but using CORS (supported in Firefox, Chrome & Safari) we would be able to 
access any data from other servers implicitly allowed using the 
Access-Control-Allow-Origin header. So that would definitely be a nice way to 
load images.  

Original comment by adeve...@gmail.com on 13 Jul 2010 at 3:20

[GoogleCodeExporter]

Now that you've got me thinking about this more, I am not sure if library side 
or SVG-edit side handling of file browsing makes the most sense. The latter 
would allow for a more consistent (and potentially better) experience for 
users, but the former (via iframe) would allow for easy handling of login 
requirements etc and would allow library developers the ability to offer up a 
variety of searching and browsing functionality tuned to the structure and 
content of their libraries.

I just put together this test browser/selector:
http://ian.umces.edu/symbols/catalog/test/

which is one way things could be set up - it searches my image library database 
for all the vector images and categorizes them. Clicking on each album opens a 
popup where the user can select the image - currently this goes to the 
permalink for that image in the main interface to the image library, but of 
course this could be changed to the required link to load the image into 
SVG-edit.

Original comment by adrianbj...@gmail.com on 13 Jul 2010 at 6:44

[GoogleCodeExporter]

Yeah, I've put more thought into this too, actually thinking in the opposite 
direction (traversing JSON files in SVG-edit in a given format using CORS). 
However, after reading your latest comment and looking into the new postMessage 
interface (which allows cross-communication between iframes/pages and currently 
has better support than CORS), the iframe method may indeed be better suited.

Or, of course, we could allow both! :D

In your case, yes, I think iframes is definitely the way to go. Whenever the 
user gets to the point that the file needs to be served, you can send it like 
this:

window.parent.postMessage('<svg...', "http://svg-edit.googlecode.com");

Though we may want the first parameter to be an object containing some metadata 
too. The second parameter defines the domain you are permitting to have access 
to the data. It could also be '*' to allow any domain.

Exciting stuff! :)

Original comment by adeve...@gmail.com on 13 Jul 2010 at 7:36

[GoogleCodeExporter]

Original comment by adeve...@gmail.com on 13 Jul 2010 at 8:51

• Changed state: Started

[GoogleCodeExporter]

Made an extension for this in r1631 that allows the browsing of local and 
external libraries (see option in main menu).

Some notes:
 - This does NOT actually load the images as their own files, which is what this issue is actually for. Instead it just opens the file for editing. I wanted to see if I could get the library browsing functionality to work first, so that's what this is for. Naturally we can also use this behavior for the purpose of browsing images just to edit, instead of just as included clip-art.
- The UI is fairly basic and will need improvement, of course.
- The included "libraries" are just a single HTML and SVG file, even more 
minimal and ugly, they're just as early demos. :) 

Personally I find it awesome that this way we can browse external sites for 
files! They do of course need to be set up with a postMessage line, but it 
still allows for plenty of possibilities. 

Original comment by adeve...@gmail.com on 14 Jul 2010 at 6:17

[GoogleCodeExporter]

This is quite interesting - I don't understand the details, but suggest working 
with folks at OCAL to get a working prototype going with real SVG files?

Original comment by codedr...@gmail.com on 14 Jul 2010 at 6:19

[GoogleCodeExporter]

Quick note: It seems that child SVG elements can't be transformed, so I guess 
we'll have to wrap them in a <g> in order to manipulate them like other 
elements...

Original comment by adeve...@gmail.com on 14 Jul 2010 at 8:30

[GoogleCodeExporter]

Jeff - Yes, certainly a good idea. And I believe adrianbjones is offering 
access to his library, so setting that up would be a nice start to this too. :)

adrianbjones - If you'd like to get started on this, I recommend looking at the 
source of this page:
http://svg-edit.googlecode.com/svn/trunk/editor/extensions/imagelib/index.html
which is the being used as a demo of how an external library can interact with 
SVG-edit. As mentioned before, the key lies in this line:

window.top.postMessage(data, "*");

(actually this should probably be window.parent) 
Let me know if you need any more information or help with this.

Original comment by adeve...@gmail.com on 15 Jul 2010 at 12:51

[GoogleCodeExporter]

Just noticed that Jeff mentioned the SVG/tranform problem in Issue 72 (on 
importing SVG). I'd forgotten about the ID problems that can occur, so will 
need to make sure those work correctly.

For now I'm thinking all imported child SVG elements should be wrapped in a 
<g>, then on export, any <g> with only an <svg> as its child should just be 
replaced by its child <svg>, providing it does not have a scale/rotate 
transform to it. Any translate transforms can be converted to the <svg>'s x,y 
values.

Selecting a <g><svg/></g> element should probably appear differently in the 
context menu from a regular group, dis-allowing ungrouping. We may want to 
internally give it a se: attribute so it's more easily identified.

Any objections to this?

Original comment by adeve...@gmail.com on 15 Jul 2010 at 1:01

[GoogleCodeExporter]

Ok, Here is a rough first draft of a selector for all the illustrations in our 
library:
http://ian.umces.edu/diagrammer/editor/svg-editor.html

You will need to register (free) for an account with our image library and 
activate it first, but after that it should be straight forward.

Let me know if you find any problems or have any suggestions.

Looking forward to these being "imported" rather than "opened".

Thanks

Original comment by adrianbj...@gmail.com on 15 Jul 2010 at 5:12

[GoogleCodeExporter]

I just added a simple search feature which allows the user to generate a custom 
popup album showing the results of their keyword search - should make finding 
what they are looking for much easier!

Original comment by adrianbj...@gmail.com on 15 Jul 2010 at 7:43

[GoogleCodeExporter]

Excellent, works great! :)

Been making good progress on the importing (mostly being able to properly 
manipulate inner SVG elements), should be able to check in tomorrow.

Original comment by adeve...@gmail.com on 15 Jul 2010 at 8:24

[GoogleCodeExporter]

Just a thought - would it be possible to be able to pass some dimension 
(transform) parameters to SVGedit along with the file. I think this will be 
important once these are being imported. Either that, or perhaps a standard 
size reduction - maybe 1/4 of the existing image area? Maybe you have thought 
of a better way to handle this already.

Original comment by adrianbj...@gmail.com on 15 Jul 2010 at 10:36

[GoogleCodeExporter]

Okay, SVGs are now imported and can largely be manipulated as expected. As per 
Adrian's suggestion, they are resized when imported so they'll also fit 
properly in the document (though more work may need to be done here).

Let me know of any bugs you find!

Adrian, is it okay with you if I add your library data to the imagelib 
extension? Didn't want to do it yet without your permission. 

Original comment by adeve...@gmail.com on 16 Jul 2010 at 3:50

[GoogleCodeExporter]

Adeveria - the new functionality looks fantastic - I am just doing an SVN 
checkout now to test it on my server.

Yes, please feel free to add our library data to the imagelib extension.

Original comment by adrianbj...@gmail.com on 16 Jul 2010 at 4:01

[GoogleCodeExporter]

Okay, great! Has now been added. Thanks for setting up the first of our image 
libraries! :) 

Some thoughts:
- Should resizing imported SVGs keep their aspect ratio by default, with shift 
allowing a non-fixed ratios?

- Should we have a "break apart" or similar option to convert the SVG to a 
group with child elements?

And a TODO:
- Allow raster images to be imported via the library browser.

Original comment by adeve...@gmail.com on 16 Jul 2010 at 4:13

[GoogleCodeExporter]

This really is brilliant - great work!

I think changing the default resizing behavior might be confusing - hopefully 
most users will be aware of the need to hold down shift to maintain the AR.

I think we definitely need to have a break apart option, because from what I 
can see at the moment it appears that there is no way for the user to edit 
these imported SVGs. I wonder if it wouldn't be better to wrap these imports in 
the SYMBOL element and have something like Illustrator's "Break link to symbol" 
option if they do want to edit. This would also have the added advantage of 
reducing file size if they want to have multiple instances of the same symbol 
on the page.

I'd be happy to include all the photos and other raster images from our image 
library once you have this raster import functionality implemented.

Very exciting indeed :)

Original comment by adrianbj...@gmail.com on 16 Jul 2010 at 4:26

[GoogleCodeExporter]

Alright, added raster image support in r1636. Unfortunately you can't use the 
same ajax request to just send the image data, it has to be converted to a data 
URL first. An example of this is shown in the local demo library. 

Will look into your suggestion on the symbol thing, thanks for the idea!

Original comment by adeve...@gmail.com on 16 Jul 2010 at 6:39

[GoogleCodeExporter]

r1643 adds an "ungroup" option to any imported SVG. It also adds a "label" 
field to the group/SVG context menu, which affects the element's child <title> 
element (I think "label" is more understandable to the user, though I'm open to 
other names).

It may be a bit confusing to people what the difference is between the ID and 
the label, so we may need to think about dealing with that. The reason I wanted 
it displayed was mostly for imported SVGs that have a <title> set (like 
many/all the IAN ones). Additionally, imported SVGs created in SVG-edit, then 
broken apart will this way have their layer names be visible, which can be 
helpful too.

One other thing I've done is made the <title> of a group be removed when 
ungrouping. Previously it was just ungrouped too, but that leads to problems as 
the title no longer describes its content and an SVG-edit layer may find itself 
with more than one <title> elements, which is not good either. Any potential 
problems with this? 

Original comment by adeve...@gmail.com on 22 Jul 2010 at 7:21

[GoogleCodeExporter]

I think the label option is great - all the IAN ones do have the title set (all 
the metadata fields are programmatically added to the SVG when we upload a new 
illustration or edit the database fields in our image library). I also agree 
with the logic of removing the title when ungrouping.

Thanks again

Original comment by adrianbj...@gmail.com on 23 Jul 2010 at 3:05

[GoogleCodeExporter]

adeveria,

What do you think about me providing access to the photos in the IAN image 
library. I was all set on adding this functionality - probably a switch to 
allow the users to filter vector/raster/both to simplify browsing, but I wonder 
how useful they would really be in SVGEdit. I see the point to having raster 
illustrations available (for when a vector alternative isn't available), but 
not sure how many people would actually want to load up a photo in SVGEdit. If 
you think it would be useful, I'd be happy to make them available though. If 
so, I would probably go with the preview sized version which has a 400px max 
width/height, rather than the full high res version as I imagine this would 
slow things down considerably.

What do you think? 

Original comment by adrianbj...@gmail.com on 23 Jul 2010 at 3:15

[GoogleCodeExporter]

Good question...it's hard to tell what the user will want, though I suspect if 
a photo was needed, it would be a specific one they already had in mind rather 
than one in a library. Customized versions of the editor may want to have a 
library with photos, but then they'd set up that library themselves.

So it's up to you, I suppose it's neat for demo purposes, but probably not much 
more. The smaller versions would indeed make more sense.

Original comment by adeve...@gmail.com on 27 Jul 2010 at 7:33

[GoogleCodeExporter]

I've started converting imported SVGs to <symbols>, though this has led me to 
the following question:

When selecting the <use> element that links to a <symbol>, and clicking the 
"break apart" button, what exactly should happen? Currently to make the element 
really editable, there's these steps necessary:

1. Convert <use> to an <svg> (internally wrapped in a <g>)
2. Convert the <svg> to a <g>
3. Ungroup the <g> (though not necessary once issue 615 is resolved)

I'm thinking steps 1 and 2 should happen in one click, to avoid too many 
annoying clicks. Unfortunately this would mean that there's no easy way to keep 
it as an <svg> if that's what's desired. Not sure how likely the user is going 
to want that, though.

I suppose in the future we could have a "convert group to <svg>" option, which 
would pretty much fix this, except any viewBox (and perhaps other) data would 
be lost. Or another solution would be to have two buttons, a "convert to group" 
and "convert to SVG", but that also seems a bit much...

Original comment by adeve...@gmail.com on 27 Jul 2010 at 7:45

[GoogleCodeExporter]

I guess from my point of view, I can't see why anyone would prefer to have 
child <svg> elements vs <g> or <symbol> elements within the one main <svg> 

Does anyone know of a likely reason to want this?

I think I mentioned it above, but would a "break link to symbol" button be 
reasonable, rather than simply ungroup, so that users know a little more about 
the structure of the inserted clipart - it would certainly be intuitive for 
Illustrator users.

Original comment by adrianbj...@gmail.com on 27 Jul 2010 at 8:41

[GoogleCodeExporter]

The only thing I can think of is when a person imports an SVG that has a 
viewBox set to only part of the image...and turning that into a group would 
reveal the entire image. Of course one would still need to do that to edit it, 
so I suppose ultimately that doesn't matter.

Yeah, I'm fine with changing the button look/name, I just went with ungroup 
since the effect seemed similar to ungrouping a group.

Original comment by adeve...@gmail.com on 27 Jul 2010 at 10:12

[GoogleCodeExporter]

Right - I didn't think about viewBox - maybe it is just me, but I have always 
thought of viewBox and clipping mask options as lazy when it comes to vector 
images. Something that might help on that front (although this probably belongs 
as a feature request) is having tools like Illustrator's divide objects 
below/eraser/knife tools. I think the eraser one has already been requested.

Original comment by adrianbj...@gmail.com on 27 Jul 2010 at 10:28

[GoogleCodeExporter]

Something just occurred to me, is there any reason we need to convert the <svg> 
into a <symbol>? From what I can tell, simply leaving it as an <svg> and 
putting that in the <defs> has the exact same effect. 

The reason I asked is because I just noticed a Firefox bug where a <symbol> 
with elements w/gradients changes all its fills to black. The same element as 
an <svg> does not have this problem.

Naturally we can still call this a "symbol" in the UI if desired, but from what 
I can tell the element doesn't add any extra functionality.

Original comment by adeve...@gmail.com on 28 Jul 2010 at 5:23

[GoogleCodeExporter]

My only thoughts on this relate to how Inkscape and other programs might handle 
these. If Inkscape was to develop symbol palette functionality like 
Illustrator, it might require the element to be <symbol>. I have also be 
playing around with trying to convert SVG to AI using Cairo - not terribly 
successful due to some PDF gradient issues at the moment, but the long term 
goal was to be able to package SVGs as symbols within a symbol palette file 
that could be opened in Illustrator. The <symbol> element would potentially 
make this conversion easier, but this is probably not an issue for svg-edit.

Original comment by tjbcarr...@gmail.com on 28 Jul 2010 at 5:35

[GoogleCodeExporter]

You know what, that's a great point. I just tried opening such a file in 
Illustrator (CS3) with two <use> elements referring to the same object. The 
result was that one was positioned correctly, but the other was not. Exporting 
the file as SVG also showed that the <svg> had been converted to two separate 
groups. Opening the same file with <symbol> instead of <svg> gave the expected 
result, also when exported.

A bug in Illustrator, of course, but it certainly illustrates your point.

So this means we have to choose between supporting vector editors or Firefox 
(and sadly Firefox 4b2 shows the same behavior. Looking at the related bug [1], 
it doesn't seem like this will be fixed any time soon, either. :( 

May be worth looking for a workaround that'll both...ugh.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=353575

Original comment by adeve...@gmail.com on 28 Jul 2010 at 6:20

[GoogleCodeExporter]

Just tested in Inkscape, thankfully it loads the file fine regardless of 
whether it uses <svg> or <symbol>. 

Original comment by adeve...@gmail.com on 28 Jul 2010 at 6:32

[GoogleCodeExporter]

Pain about the illustrator and FF bugs. Great that it loads fine in Inkscape - 
still doesn't address the added functionality that the symbol tag may offer in 
Inkscape in the future, but as I mentioned, maybe this really isn't too 
relevant to svg-edit and/or maybe that could be addressed when/if the time 
comes. 

Original comment by adrianbj...@gmail.com on 28 Jul 2010 at 7:14