Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
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
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
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
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
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
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
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
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
#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
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
[deleted comment]
[deleted comment]
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
#62 has been taken care of by r75 of CanVG
Original comment by adrianbj...@gmail.com
on 17 Aug 2010 at 5:58
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
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
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
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
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
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
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
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
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
I think "Open as new document" sounds better for sure.
Original comment by adrianbj...@gmail.com
on 17 Sep 2010 at 8:32
Original issue reported on code.google.com by
Christia...@gmail.com
on 10 Jul 2009 at 11:30