Re: Things I wanted to see in SVG 1.2, but aren't yet mentioned.

Jim Ley wrote:

>"Thomas E Deweese" <thomas.deweese@kodak.com> wrote in message
>news:16100.28579.388328.981520@frog.rl.kodak.com...
>  
>
>>JL> Unfortunately not, as it will require scripting, and as you note
>>JL> there are other simpler ways of having sizes in PNG etc. - it
>>JL> should be a simple operation of including an image as it is with
>>JL> including an SVG image.
>>
>>    I guess I don't follow you.  The 'image' element always requires a
>>w/h specification - it doesn't matter if the referenced content is
>>raster or SVG.
>>    
>>
>
>http://lists.w3.org/Archives/Public/www-svg/2002Jul/0011.html  and later
>discussion, is what I'm talking about, this issue was rejected in SVG 1.1,
>I'm still looking for a solution.
>
    Ahh, I had forgotten that when viewBox is not specified on the 
referenced SVG width/height
are ignored on image (I never generate svg content w/o a viewbox - I 
actually think this should have
been required).

>>I know that some formats may provide 'real world' unit mappings
>>(which could be sensibly treated as CSS units) but what about images
>>that don't include this information?
>>    
>>
>
>Images that don't include this information can be treated as currently,
>those that do contain the information, should use that information.
>Refusing to trust a higher level information is not friendly, I fail to see
>why it's okay to ignore the size information?
>  
>
    One really good reason to ignore this information (at least by 
default), is that often it is wrong and tools to view and edit this 
information are not widely distibuted.  So authors may be very confused 
why an image
'abc' refuses to respect width/height when the 23 other images they 
reference do.  There was at one time
talk of adding a 'defer' value to preserveAspectRatio - perhaps 
something similar could be added for
width/height.

>>    I guess I don't have a problem with requiring authors to say how
>>large they want the referenced content to appear in the document.  Why
>>is this an issue for you?
>>    
>>
>
>Because me and lots of people I talk to have huge amounts of legacy content
>where there have a raster image, and areas defined in co-ordinates of that
>raster image, but do not know the size of the image (consider HTML image
>maps for example). 
>
    This legacy content still needs to be transcoded and it seems like 
downloading an image tool like
ImageMagik for perl so you can access this information would be a very 
small amount of additional
work.

>I've also previously wanted to create an Image
>Annotation tool, that allows users to add an image, and then draw on the top
>of it, (an HTML image map creator say, where the co-ordinate space needs to
>be in terms of the size of the raster) to do this I need to know the size of
>the image, that's not possible in SVG, even with scripting.
>
   

>>In most cases I can think of where this
>>might be an issue scripting would be a perfect solution.
>>    
>>
>
>How exactly?  scripting provides no access to the size of an image.
>
    Currently no, but the section referenced by Chris does mention the 
possability of providing DOM based access to metadata in raster images.  
The WD currently says they may not define this interface, but I think
that the public should strongly encourage the specification of at least 
a few very common fields, such as 'width', 'height' and 'comment'.  
There are a number of XML definitions of EXIF data one of which could 
also be referenced (even if only with a 'should').

Received on Monday, 9 June 2003 09:08:36 UTC