Revision as of 19:18, 12 November 2005

Elliptic Arcs

Path elements in SVG

SVG specification: http://www.w3.org/TR/SVG/paths.html#PathDataEllipticalArcCommands.

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 ([

Current status

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 .

Further steps

There are the obvious four options in order of decreasing intrusiveness:

1. 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).
2. should not take advantage of the gap in the specification and support the complete path specification. This issue is not yet filed.
3. could stay agnostic against elliptic arcs but care for graceful degradation when opening/importing OpenDocument documents. This is requested in Issue:41343 .
4. This is what's done since version r2009 of SVG import: The [[[Main_SVGImportFilter|SVGImportFilter]]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.

-- Main.BernhardHaumacher - 20 Aug 2005

Discussion

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.

IMO, resolving the issue within OpenDocument (and/or ) is the appropriate solution. Only if no target milestone can be assigned to that, support within the filter is worthwhile.

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.

-- Main.BernhardHaumacher - 20 Aug 2005

test-elliptic-arcs-and-cubic-splines.odg Approximation of elliptic arcs with cubic splines.