Difference between revisions of "Unsupported SVG Features"

Revision as of 17:18, 3 January 2006

The SVG features mentioned on this page are currently not supported. For some, there are good reasons why the import filter cannot handle them, some were just considered less important. If your SVG graphic uses these features, they are silently ignored and your imported graphic may look "somewhat broken".

General note

SVG and what's named SVG-compatible in OpenDocument is really different. Therefore, the import filter can only approximate the SVG contents. In case of doubt, the approximation accepts visual differences for preserving editability. If you fell that your SVG document was not processed correctly, please also check the SVGSupportedFeatures section for potential restrictions.

Stroke opacity

Due to Issue:42959, this is disabled in the current version of the filter. Strokes are always imported fully opaque.

Since Issue:42959 is fixed in current builds of , the upcoming version of the import filter will enable the import of stroke opacity.

Embedded images (image)

Images (e.g. bitmaps) that are referenced from the imported SVG graphic are not imported into .

I consider this less important, because embedded low-resolution bitmaps produce inferior results when being scaled or printed.

The OpenDocument format supports embedding images even in its flat-XML flavor produced by the SVG import filter. The binary coded data must therefore be embedded within a office:binary-data element. This of cause results in increased file sizes, if the SVG file links to the same image multiple times, because each copy is embedded (by value) in the resulting document.

Special text (textPath / a / tref / tspan)

Needs further evaluation.

Patterns and line dashing

Needs further evaluation.

When the image contains pattern fills, this currently breaks the import. The filter fails with a "General input/output error" and nothing is imported.

Clipping (clipPath / mask)

Clipping is not supported by OpenDocument. The only workaround is to pre-clip graphics elements during import. This workaround requires a set of "algebraic" operations on primitive graphic elements (like the intersection and subtraction of shapes as implemented in Draw). Even if this seem to be challenging, the resulting graphics will become less editable.

Clipping is currently not implemented in the import filter. If your SVG graphics relies on clipping, you will see primitive graphics elements in the imported result that are "somewhat to large".

Other funny stuff

Descriptive elements, embedded fonts, filters, animation, color profiles, cursors, foreign objects, scripting, switch and view is silently ignored.

Apart from descriptive elements, which should be translated into named graphics objects, I consider this of no relevance for Draw applications.

Known Bugs

Fixed in version r2009: Loading of documents fails, if width and height attributes are missing on the top-level svg element.

In that case, a Java:java/lang/NullPointerException is displayed in the console window, from where was invoked and the loading fails with a general input/output error. You can add the missing attributes in a text editor and try again to import the graphics.

The exception reads as follows:

java.lang.[[Main_NullPointerException|NullPointerException]]
	at org.apache.batik.dom.svg.[[Main_AbstractSVGLength|AbstractSVGLength]]$[[Main_DefaultContext|DefaultContext]].get[[Main_ViewportWidth|ViewportWidth]]
	at org.apache.batik.parser.[[Main_UnitProcessor|UnitProcessor]].percentages[[Main_ToPixels|ToPixels]]
	at org.apache.batik.parser.[[Main_UnitProcessor|UnitProcessor]].svg[[Main_ToUserSpace|ToUserSpace]]
	at org.apache.batik.dom.svg.[[Main_AbstractSVGLength|AbstractSVGLength]].getValue
	at haui.xml.svg.[[Main_DefaultUserAgent|DefaultUserAgent]].get[[Main_ViewportSize|ViewportSize]]
	at org.apache.batik.bridge.[[Main_UserAgentViewport|UserAgentViewport]].getWidth
	...
	at org.apache.batik.bridge.[[Main_UnitProcessor|UnitProcessor]].svg[[Main_LengthToUserSpace|LengthToUserSpace]]
	at org.apache.batik.bridge.[[Main_UnitProcessor|UnitProcessor]].svg[[Main_HorizontalLengthToUserSpace|HorizontalLengthToUserSpace]]
	at org.apache.batik.bridge.[[Main_SVGSVGElementBridge|SVGSVGElementBridge]].create[[Main_GraphicsNode|GraphicsNode]]
	at org.apache.batik.bridge.GVTBuilder.build
	at haui.xml.svg.SVGBuilder.completeLoading
	at haui.xml.svg.SVGBuilder.loadDocument
	at haui.office.uno.filter.svgimport.[[Main_SVGImportService|SVGImportService]].importer

-- BernhardHaumacher - 18 Aug 2005