Re: Copy and Paste SVG

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:
> http://lists.w3.org/Archives/Public/www-svg/2004Mar/0172.html
> 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):
   http://schepers.cc/testbed/copyPaste/CopyPaste.html

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.

Regards-
-Doug

Received on Sunday, 8 July 2007 08:49:57 UTC