Supported SVG Features
| SVG Import|
The following SVG vocabulary is supported in the latest version of the import filter. To import most simple drawings, this is nearly sufficient. If you had other experience, please feel free to report them at SVGUserExperiences.
Basic drawing elements
circle, ellipse, image, line, polygon, polyline, rect, text
- Update: Rare problems with horizontal and vertical lines should be gone with filter version r2009. The import filter now implements a workaround for Issue:36713 and normalizes viewbox coordinates to units of mm/100.
- Update: The problem with invisible areas that is due to a different semantic of non-closed paths in SVG and OpenDocument/ is fixed in filter version r2009. An additional normalization for non-closed but filled paths is used. For details, see SVGPathSemantics.
SVG and OpenDocument support the same set of path segments (moves, straight lines, various flavors of Bezier curves and elliptic arcs). However, currently does not completely implement the OpenDocument specification regarding elliptic arcs. Therefor, with (version r2009), the import filter provides an approximation for elliptic using possibly multiple cubic splines.
Visual differences are hardly perceivable, but editing of circle and ellipse segments becomes harder after import. With that approximation behavior, is in good company, since even the popular SVG editor Inkscape does not support elliptic arcs for editing. For a detailed discussion, see SVGEllipticArcs.
Groups svg, g
The filter fully supports nested transformations in SVG. To produce legal OpenDocument, all transformations on container elements are collapsed into a single office transformation per basic graphics element. For more details, see SVGCoordinateSystems.
Symbols (symbol / use)
SVG graphics may render parts of a graphic multiple times in different contexts. A graphics symbol is defined with the symbol element and rendered with the use element. In SVG editors, this construct is created with the clone operation.
Since there is no equivalent for symbols in OpenDocument, the only way to deal with these constructs is to expand all usages of a symbol with a copy of the symbol itself. This is done with version 2009 of the import filter. Importing graphics with symbols causes no visual differences, but reduces the additional structure that was present in the SVG file.
Complete CSS styling with style elements, style attributes and class attributes is supported. This feature is simply inherited from the underlying batik SVG engine. Many CSS properties are supported and converted into the corresponding text and graphic style. For more details, SVGStyleProperties.</dd>
A graphics element is fully opaque, if the background does not show through. Opacity is measured in percentages from 100 (fully translucent). SVG supports three flavors of opacity, stroke, fill and group opacity. Unfortunately, OpenDocument does only know of stroke and fill opacity. Since group opacity cannot be fully emulated using the former, you may experience visual differences, if your SVG image uses group opacity values of less than 100%. For details, see SVGGroupOpacity.
Gradients defined in SVG are also available in OpenDocument. Unfortunately, does currently not implement this part of the OpenDocument specification and ignores so called "SVG gradients". The import filter approximates SVG gradients with "draw gradients". Since draw gradients are far less expressive, this approximation is This is very basic and you may observe major visual differences. For details, see SVGGradients.
Line endings may be decorated with markers. Since the marker functionality specified in OpenDocument is to inexpressive, the transformation expands markers and creates separate graphic objects for each occurrence of a marker. This makes editing the resulting document harder, but is the only way to support SVG markers in general.
-- BernhardHaumacher - 18 Aug 2005