W3C home > Mailing lists > Public > www-svg@w3.org > March 2008

(unknown charset) Re: [Bug 5560] Image inclusion with <image> depends on referent's coords

From: (unknown charset) ~:'' ありがとうございました。 <j.chetwynd@btinternet.com>
Date: Wed, 12 Mar 2008 09:41:32 +0000
Message-Id: <CBD1D6EE-7767-4A11-AA03-BF71F1E8619F@btinternet.com>
Cc: (unknown charset) svg-developers@yahoogroups.com
To: (unknown charset) www-svg List <www-svg@w3.org>

flickr indicates the huge commercial and social benefits in providing  
a simple means to share images.
SVG has singularly failed to provide anything even vaguely similar.
One reason being the difficulty in repurposing svg graphics, which  
this bug seeks to ameliorate.
Another being the failure to ensure <title> content is included in  
documents.

However whilst at the corporate level there is little problem  
providing any one of a number of means to label images by category,
as an individual, it seems  there may be another semantic deficiency  
with the spec:

<use> enables the author to provide a number of internal and external  
referenced svg graphics in a category document, including  
agglomeration of categories. However there may be significant  
problems scaling externally referenced svg graphics.

<image> (will?) scale externally referenced svg graphics, but there  
is no possibility of relying on, or agglomerating other authors  
categories by document via <image>.

it might be possible to reference category documents of <images> with  
#ids with <use> but this seems a somewhat unnecessary and unreliably  
complex methodology for something that is clearly required by many  
and should be simple to create.

In particular, people with learning disabilities, like us all rely on  
a limited set of images, and they will benefit from simple methods  
that allow them to create and share private categories of images.

regards
  	
Jonathan Chetwynd

j.chetwynd@btinternet.com
http://www.peepo.com/

+44 (0) 20 7978 1764


On 11 Mar 2008, at 22:28, bugzilla@wiggum.w3.org wrote:


http://www.w3.org/Bugs/Public/show_bug.cgi?id=5560

            Summary: Image inclusion with <image> depends on referent's
                     coords
            Product: SVG
            Version: SVG 1.1 Full
           Platform: All
         OS/Version: All
             Status: NEW
           Severity: normal
           Priority: P2
          Component: Coordinate Systems
         AssignedTo: schepers@w3.org
         ReportedBy: mark@kli.org
          QAContact: www-svg@w3.org


You can include an image in an SVG, and if it is a raster image, you can
specify its size and position in the local (referring) SVG's  
coordinate system
and everything will scale just right no matter what size the actual  
PNG is.
e.g., <image x="-50" y="-50" width="100" height="100"  
xlink:href="pic.png"/>
will have the picture centered on (0,0) in the current co-ordinate  
system and
stretching from -50 to 50 in whichever dimension is its largest, no  
matter how
big pic.png really is.  This cannot be done if the included image is  
an SVG,
making SVGs actually *less* scalable and portable than raster images,  
which
seems to defeat their purpose.  The specs say:

"The value of the 'viewBox' attribute to use when evaluating the
preserveAspectRatio attribute is defined by the referenced content.  
For content
that clearly identifies a viewBox (e.g. an SVG file with the 'viewBox'
attribute on the outermost svg element) that value should be used."

Which is probably necessary for some applications, but it should be  
defeasible.
  There ought to be a way for the referring SVG to force the viewBox  
to be
scaled into its own co-ordinates, so we can do the same sort of thing  
as can be
done with raster images.  The SVG being included might not be under  
the same
control and authorship as the referring SVG, and the spec seems to  
assume it
is.  Maybe something like a "useLocalCoords='yes'" attribute or  
something?
Received on Wednesday, 12 March 2008 09:41:55 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:38 GMT