SVG Elliptic Arcs

From Apache OpenOffice Wiki
Jump to: navigation, search
SVG Import
(external impl.)
Source code
Group opacity
Elliptic arcs
Path semantics
Coordinate systems

Path elements in SVG

Besides straight lines, quadratic and cubic Bézier curves, a path in SVG may consist of elliptic arcs. For details, refer to the path section of the SVG specification: [[1]].

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.

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

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.

-- BernhardHaumacher - 20 Aug 2005

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

Personal tools