OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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.:

<display-width value="2in"/>
<display-height value="2in"/>

This requires no architectural change but is slightly less convenient to

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.


Eliot Kimber, Owner
Contrext, LLC

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]