Re: Copy and Paste SVG


thanks for the carefully thought out response, I've attached a couple  
of links that might be of interest.

I'm really only interested in copying and pasting SVG as an SVG  
graphic with RDF where relevant...
not raster or other.... this is possible with Amaya.

we really need to define what and how to copy and paste SVG

I raised a Copy and paste bug with each of the native SVGUA:

Opera #234454
Amaya see below for some functionality at one time....
Webkit server down so have to wait....



Jonathan Chetwynd

** description of Amaya functionality attached to Opera and Mozilla bugs

download amaya

my test was on a short animation:

open the link above in amaya
open a new xhtml document in another window or tab
select some part of the svg in the amaya logo
paste into the new document
view source
graphic is copied with transforms but not animateTransform

this is rather buggy at present at least for me in os x, but does  
work with patience.

On 8 Jul 2007, at 09:47, Doug Schepers wrote:

Hi, Jonathan-

~:'' ありがとうございました。 wrote:
> where are the SVGWG descriptions or specifications defining what  
> and how the user can copy and paste graphics in SVG?
> that is parts rather than a whole SVG.

Unfortunately, the only mention of copy and paste in the SVG spec  
that I'm aware of is regarding text, not graphics in general.  We  
have discussed the idea of recommending that appropriate UAs permit  
the copying/saving of rasterized versions of the SVG, but I don't  
know that anything has been put in a spec yet.  I'd still like to do  
this for 1.2 Full.  Anne van Kesteren made a suggestion to me that we  
align with the <canvas> specification on this behavior, which sounds  
reasonable to me.

As far as copying specific parts of a total SVG, I think that should  
be covered in the Clipboard spec, under the topic of structured  
content. We are somewhat constrained there, since ideally we would be  
specifying behavior that matches what IE or other browsers already do  
(or at least that was the initial idea), and copying rich content  
(multiple modalities) is not covered very well there.

> I found this regarding copy and paste SVG in IE:
> but no link to your demonstration...

My demo only works in a browser with the "clipboardData" interface  
(which so far as I know is only IE):

It doesn't really do what you want, though... if you copy a  
particular graphic, it can be pasted into another SVG with the  
corresponding bit of script, but if you paste it into Word or some  
other interface, it will just paste the string of code that renders  
as that graphic, not the graphic itself (not even as a static raster).

It would indeed be ideal if we could expect multiple pasting options  
(and Word does have "Paste Special", though that doesn't help with my  
demo), where the user could choose whether they want to paste the  
copied content as a "flattened" version (plain text or a rasterized  
graphic), or its presentational form (a "rich text" passage or a  
normalized SVG graphic that contains all the styling information that  
creates the final form of the graphic), or to expose the structure  
behind the copy selection (such as the markup itself as text).  This  
is probably outside the purview of a W3C spec, though, since it would  
depend upon the native clipboard capabilities of the device and the  
operating system.

As a side note, there are some interesting open questions about  
metadata with regards to copy and paste.  A raster image will  
probably contain some metadata (in any of a wide number of formats)  
in addition to the binary bits of the image that make up the picture  
itself, and the expectation would be to copy and paste that when  
duplicating the image.  An SVG image might also contain metadata  
(either in the form of <title> and <desc>, or as RDF, or whatever);  
if you copied a particular element, would you expect any child  
content metadata to travel along? (I would.)  But what if it were  
rasterized as part of the pasting process?  Should the metadata be  
embedded?  If so, in what format?  What if you copy a picture from a  
Web page, and the <image> element contains an @alt... would that ever  
be preserved?  Perhaps if you were copying from one Web page into  
another, or into an HTML/SVG/your-markup authoring tool?  Would it  
always be external metadata in the markup, or might it be integrated  
into the raster's own internal metadata? Interesting issues, to me...

But again, probably better discussed over in WebAPI.


Received on Sunday, 8 July 2007 09:51:23 UTC