OpenDocument SVG Correspondence

Section 9.2 (pp275-) of the OpenDocument specification (available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office) is the most obviously related to SVG.

9.2 Drawing Shapes

9.2.1 Rectangle

draw:rect element: svg:rect (http://www.w3.org/TR/SVG11/shapes.html#RectElement)

draw:corner-radius attribute: rx. (OpenDocument has no equivalent of specifying both rx and ry, so we may forbid specifying ry in OpenDocument SVG fragments.)

9.2.2 Line

draw:line element: svg:line (http://www.w3.org/TR/SVG11/shapes.html#LineElement)

9.2.3 Polyline

draw:polyline element: svg:polyline (http://www.w3.org/TR/SVG11/shapes.html#PolylineElement)

svg:points attribute: points. The OpenDocument specification is (at first glance at least) ambiguous as to whether coordinates can contain units, whereas the SVG spec disallows units.

9.2.4 Polygon

draw:polygon element: svg:polygon

9.2.5 Regular Polygon

draw:regular-polygon element: svg:path supplemented by draw:blah attributes used as hints to editing programs (similar to the star tool in inkscape).

(Note that svg:polygon doesn't in general suffice, because of the draw:sharpness attribute.)

Consider hinting only what cannot be inferred from the path data, to reduce problems from conflicts between the path data and hints.

9.2.6 Path

draw:path element: svg:path.

svg:d attribute: d. (Though note the OpenDocument comment "Some implementations may only supports a subset of the SVG path specification, for instance no mixtures of open and closed curves for one shape, or no elliptical arc command.")

9.2.7 Circle

draw:circle element: can use svg:circle if draw:kind="full"; all kinds can be represented with svg:path. (http://www.w3.org/TR/SVG11/paths.html#PathDataEllipticalArcCommands for the curved part).

Note that in OpenDocument, its svg:cx and svg:cy attributes may be inferred from the position & size attributes (see section 9.2.15 below), whereas in SVG 1.1 cx and cy each default to 0 if unspecified.

In OpenDocument, absence of svg:r attribute means that the radius is to be calculated from the size attribute[*1], whereas SVG 1.1 requires an r attribute.

[*1]: The specification actually says calculated from both size and position attributes, though I think position is irrelevant, whereas I'd guess that the svg:start-angle and svg:end-angle attributes are relevant. The OpenDocument specification gives no further information about how to calculate radius.

For converting between OpenDocument's start-angle,end-angle format to SVG's endpoint representation, see http://www.w3.org/TR/SVG11/implnote.html#ArcImplementationNotes, principally sections F.6.4 and F.6.5.

9.2.8 Ellipse

draw:ellipse element: Can use svg:ellipse if draw:kind="full"; the more general case is as for draw:circle (see above) except for its svg:rx and svg:ry attributes instead of svg:r.

OpenDocument allows svg:rx and svg:ry to be inferred from position & size attributes, whereas the rx and ry attributes of svg:ellipse are required.

(The OpenDocument spec has a typo saying svg:rx twice instead of "svg:rx and svg:ry".)

9.2.9 Connector

draw:connector element: svg:path supplemented with hints for editor programs.

The OpenDocument spec doesn't seem very specific about how draw:connector elements are rendered. I didn't understand its "escapes" terminology.

[Comment: A possible specific interpretation of the spec is as follows: The connector is connected to a glue point that can be at a specified location in the shape, not necessarily on the edge. The connector line is drawn from the glue point, but might not be rendered until it "escapes" the shape by crossing the edge.]

draw:{start,end}-{shape,glue-point} may be retained as editing hints. (They should not affect positions of connectors, which would be fully specified in the path's d attribute. This allows plain (OpenDocument-unaware) SVG renderers to render the document correctly.)

draw:line-skew attribute: fully encoded in the path's d attribute. (The behaviour of draw:line-skew isn't fully specified in the OpenDocument specification.)

9.2.10 Caption

draw:caption: svg:g.

Editing hints that may be useful:

• Make the children of the group editable without explicitly entering/opening the group: allow typing directly into the text element, and allow changing the radius of the caption box.
• Use connector facility to manage the lines between the "caption point" and the text & frame.

9.2.13 Page Thumbnail

draw:page-thumbnail element: svg:use (http://www.w3.org/TR/SVG11/struct.html#UseElement).

draw:page-number attribute: appears to be subsumed by svg:use's xlink:href attribute.

9.2.14 Grouping

draw:g element: svg:g

svg:y attribute: Relevant to how the draw:g is embedded inside for example textual data. This information would go on the embedding element.

If the intent of the svg:y attribute is to tie the positioning to the picture instead of the embedder (e.g. if the picture is glyph-like, in which the "baseline" is an inherent property of the glyph), then this can be achieved either by making the reference point the (0,0) of the <svg:svg> element, or perhaps using the svg:view element (http://www.w3.org/TR/SVG11/linking.html#ViewElement).

9.2.15 Common Drawing Shape Attributes

Name

The OpenDocument specification doesn't mention the interpretation or use of its draw:name attribute. Probably it's a human-readable name used only in dialog boxes of editors for OpenDocument documents. If so, then it can stay as draw:name, and can safely be ignored by most SVG user agents.

Position

The OpenDocument standard allows specifying svg:x and svg:y attributes (though in some cases doesn't mention their interpretation; probably ignored); whereas the SVG 1.1 spec allows x and y attributes on only a few elements (typically those that don't otherwise specify their position).

Size

The OpenDocument standard allows specifying a svg:width and/or svg:height attribute for many shapes, typically saying that these attributes "may" be ignored. The SVG 1.1 standard does not allow specifying width or height attributes other than for rect, image, foreignObject, and a few other things (see http://www.w3.org/TR/SVG11/attindex.html).

Transformation

draw:transform attribute: transform.

SVG 1.1 says that individual transforms are separated by "whitespace and/or a comma" whereas OpenDocument spec says they are separated by "a white space and/or a comma", which may mean that OpenDocument format allows only one whitespace character, or possibly only a literal space character (ASCII 0x20); though this may simply be a typing mistake in the OpenDocument spec.

Both specifications say [a minor rearrangement of] "The available types of transform definitions include" (emphasis not in original), which might be interpreted as indicating an incomplete list of possibilities. The SVG 1.1 spec uses "includes" elsewhere in contexts that suggest it is to be interpreted as meaning "consists of" (i.e. a complete list).

The set of allowable transforms (and their syntax) is the same, with the following exception:

rotate in OpenDocument does not allow the cx,cy arguments (which are optional in SVG1.1). The behaviour in SVG 1.1 in their absence is identical to the OpenDocument behaviour, so the revised OpenDocument format could forbid them.

View Box

svg:viewBox attribute: N.B. this differs markedly in semantics from SVG's viewBox attribute, despite sharing the same syntax. In OpenDocument, svg:viewBox is required (I believe) on the draw:path element and on elements that allow an svg:points attribute (draw:polyline, draw:polygon, and some similar things outside of section 9.2).

Further, the OpenDocument spec says "Some implementations may ignore the view box attribute. The implied coordinate system then has its origin at the left, top corner of the shape, without any scaling relative to the shape."

The OpenDocument spec doesn't say much about the interpretation of the svg:viewBox attribute: in particular, it doesn't specify how to convert the svg:points or svg:d data into the coordinate system of the corresponding polyline/path element. Possibly the corners of the specified svg:viewBox are to be mapped to the size & position attributes of the corresponding shape.

In SVG 1.1, the viewBox attribute (http://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute) isn't allowed on any "normal shapes", but on "container"-like elements (like svg, symbol, image, foreignObject; not g) and view.

When translating OpenDocument svg:viewBox use to SVG, one could wrap the path/polyline with a new svg:svg element with a viewBox attribute; alternatively, one might just apply the transformation to the point list (if the transformation is known in advance; this may not be the case when mixing units).