Closed GoogleCodeExporter closed 8 years ago
button proposal
Original comment by Christia...@gmail.com
on 11 Jul 2009 at 12:14
Attachments:
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
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
Issue 156 has been merged into this issue.
Original comment by codedr...@gmail.com
on 1 Sep 2009 at 3:37
Original comment by codedr...@gmail.com
on 26 Oct 2009 at 3:55
Original comment by codedr...@gmail.com
on 26 Oct 2009 at 4:06
Original comment by codedr...@gmail.com
on 18 Dec 2009 at 7:56
Original comment by codedr...@gmail.com
on 9 Jan 2010 at 11:08
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
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
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
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
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
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
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
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
[deleted comment]
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
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
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
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
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
Original comment by adeve...@gmail.com
on 13 Jul 2010 at 8:51
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Original issue reported on code.google.com by
Christia...@gmail.com
on 10 Jul 2009 at 11:30