This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5560 - Image inclusion with <image> depends on referent's coords
Summary: Image inclusion with <image> depends on referent's coords
Status: NEW
Alias: None
Product: SVG
Classification: Unclassified
Component: Coordinate Systems (show other bugs)
Version: SVG 1.1 Full
Hardware: All All
: P2 normal
Target Milestone: Test Suite
Assignee: Doug Schepers
QA Contact: SVG Public List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-11 22:28 UTC by Mark Shoulson
Modified: 2008-03-11 22:28 UTC (History)
0 users

See Also:


Attachments

Description Mark Shoulson 2008-03-11 22:28:26 UTC
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?