SVG Elliptic Arcs
| SVG Import|
Path elements in SVG
An elliptic arc consists of an arbitrary segment of an ellipse. Elliptic arcs are necessary to include circle or ellipse segments into paths, since elliptic arcs cannot exactly described using quadratic Bezier curves.
Path elements in OpenDocument
OpenDocument version 1.0 adopts the specification of path elements almost unmodified from SVG (see section 9.2.6 Path). Unfortunately, OpenDocument softens this specification by allowing conforming applications to only support a subset of the path specification. Unfortunately, it is not specified, what applications should do, if they encounter documents that contain path segment types they do not understand.
Path elements in
Currently, takes advantage of this gap in the specification and does not support elliptic arcs. Even worse, does not care about graceful degradation, but silently ignores elliptic segments completely. This behavior obviously breaks OpenDocument documents that contain paths with elliptic arc segments, when opening them with . Issue:41343 deals with that problem.
Consequences for SVG Import
When taking OpenDocument literally, it is not necessary to touch path segments, since they are almost the same in both formats (apart from different namespaces of their containers). Due to the missing strictness of the OpenDocument specification, this is not true in reality. When importing SVG into , elliptic arc segments must be replaced with an approximation that guarantees graceful degradation. Otherwise, the resulting document becomes unusable.
Experimental results ([/test-elliptic-arcs-and-cubic-splines.odg test-elliptic-arcs-and-cubic-splines.odg]) show that elliptic arcs that span less than 90° of a circle or ellipse can be approximated with a single cubic Bézier spline. The visual differences are almost below the rendering quality of . However, elliptic arcs that span more than 90° must be split to produce acceptable results.
Currently (version r2009), the SVG import filter transforms elliptic arcs into a sequence of cubic splines. This is the not the best option but the only one viable outside .
There are the obvious four options in order of decreasing intrusiveness:
- The OpenDocument specification should be fixed to disallow conforming applications to break the user's documents (either it should be disallowed not to support the full path specification, or applications should be obligated to care for graceful degradation).
- should not take advantage of the gap in the specification and support the complete path specification. This issue is not yet filed.
- could stay agnostic against elliptic arcs but care for graceful degradation when opening/importing OpenDocument documents. This is requested in Issue:41343 .
- This is what's done since version r2009 of SVG import: The SVG_Import_Filter SVG import filter] could preprocess path segments and replace all elliptic arcs in paths with an approximation using cubic Bézier splines. Obviously, this is only a workaround for the problem, since will keep breaking OpenDocument documents that are prepared using (potential) office suits that support the full path specification.
Update: Even Inkscape, a popular SVG editor, does not support elliptic arc segments in paths for editing. Instead, it also approximates them with a sequence of cubic splines.
-- BernhardHaumacher - 20 Aug 2005
Missing elliptic arcs are a main obstacle for SVG import, because SVG editors like Inkscape do also use path elements with a sequence of elliptic arcs as replacement for circle and ellipse elements. As result, everything that's round is missing after import into. This is not acceptable.
Update: Graceful degradation should be "easily" possible, because already supports a special case in the "Convert to curve" function. When the user explicitly requests to break a ellipse into a curve, the ellipse is properly approximated with four spline segments.
-- BernhardHaumacher - 20 Aug 2005