- From: Chris Lilley <chris@w3.org>
- Date: Wed, 13 Nov 2002 11:33:54 +0100
- To: www-svg@w3.org, "Jim Ley" <jim@jibbering.com>
Hello Jim, www-svg, You wrote http://lists.w3.org/Archives/Public/www-svg/2002Jul/0019.html > Aswell as this basic metadata though, there is also more complex > metadata stored in images, notably in the Adobe XMP format which > embeds RDF metadata inside the blocks, tools such as the W3's RDFPic > and Adobes own tools can generate such XMP [1] blocks. I'd like this > available because of the options it opens up, and the simple > implementation (with a 5 line perl script you can add it to > SVG/Batik, but that relies on the server loading the image aswell as > the client, which is obviously not the same.) There are two separate issues here. One is the access of one DOM from another, across a link (as happens with for example a symbol element and the corresponding use element). The other issue, which is problematical, is the access to image metadata of whatever image format in a regular fashion. There are so many raster image formats and for each, there are multiple and often incompatible ways to add metadata into them ranging dfrom unstructured commentsto EXIF to proprietary and undocumented binary blobs. It seems a rather large task to expect a single raster image DOM, independent of format and independent of how the metadata got shoehorned into the image file and what schema it uses, to be able to get the width (or the photographer, or the focal length). It might be possible, but its a large task and not directly related to SVG. If and when such a thing was done, though, I agree that having a DOM method on the image element that could give you a bridge into this raster DOM would be a natural development. -- Chris mailto:chris@w3.org
Received on Wednesday, 13 November 2002 05:33:53 UTC