[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Potential Missing Feature for Inline SVG: Display Width and Height
In implementing output processing for inline/referenced SVG for DITA 1.3 I've discovered that there's a small missing feature, namely the ability to specify an explicit width and/or height for the SVG. The <image> element provides @width and @height but the <foreign> element does not. Thus, there is currently no container one can put around an <svg-container> element or attributes one can specify on <svg-container> that let an author specify the desired display width and height. SVG drawings can specify an intrinsic absolute width and height but they do not need to. When not specified the SVG graphic is intended to be scaled to fit the "current viewport". In the case of XSL-FO output, the width of the viewport will be the width of the containing block, which would normally be the width of the current column. In my tests with Antenna House such a graphic is rendered scaled up to fit the width of the current column. My initial reading of the SVG spec is that this is the correct behavior. Batik and all the browsers I've tested with render the graphic as though the viewport was as wide in pixels as the graphic's specified view box (the SVG viewBox attribute specifies how the graphic's local coordinate space should be mapped to the outer coordinate space--the view port. The browsers and Batik appear to be inferring a viewport that is the view box width and height in pixels but I could find nothing in the SVG spec that supports this behavior. SVG graphics that specify a viewBox but no explicit width or height should be the normal case as such graphics are inherently scalable, while graphics that specify an explicit width and height are not. I think this means that we need to define a way for DITA document authors to specify explicit width and height for inline SVG graphics. I see these possible solutions: 1. Add @width and @height to <foreign>. This is an architectural change but would be easy to implement and is backward compatible. It would be useful for any use of foreign to contain data for which a width or height is meaningful. 2. Define specializations of <data> for use within <svg-container> (or within <foreign> generally) that specify width and height, e.g.: <svg-container> <display-width value="2in"/> <display-height value="2in"/> <svg:svg>...</svg:svg> </svg-container> This requires no architectural change but is slightly less convenient to author. 3. Do nothing and let the community define a convention that would be very much like option (2) or possibly some use of processing instructions but would not be part of the standard. I think I prefer option (1): It's simple and obvious and doesn't break anything. It makes <foreign> used for graphical data more parallel with <image> and doesn't risk tagname conflicts with existing custom domains. It would not require new element reference entries. Cheers, Eliot ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]