libsvgdom
libsvgdom is an SVG Full 1.1 processing library, which allows you to parse, manipulate and generate SVG content.
Table of Contents
Purpose
libsvgdom is designed to simplify generic SVG processing and manipulations. Unfortunately, an SVG is very complex format (PDF spec is 826 pages long), with lots of features and implementing all of them will lead to an enormous library.
That's why libsvgdom supports only static subset of an SVG. No scripts, external resources and complex CSS styling. Parser will convert as much as possible data to a simple doc->elements->attributes structure.
For example, the fill
parameter of an element can be set: as an element's attribute,
as part of a style
attribute, inside a style
element as CSS2, inside an ENTITY
,
using a JS code and probably with lots of other methods.
Not to mention, that the fill
attribute supports 4 different types of data.
With libsvgdom
you can just use node.has_attribute(AttributeId::Fill)
and don't worry where this
attribute was defined in the original file.
Same goes for transforms, paths and other SVG types.
The main downside of this approach is that you can't save original formatting and some data.
Example
Original image:
<!-- Comment -->
Text
How it will be represented and saved using svgdom:
<!-- Comment -->
Text
And even though the file is a bit different now - it will be rendered exactly the same.
Documentation
Benefits
- The element link(IRI, FuncIRI) is not just text, but actual link to another node.
- At any time you can check which elements linked to the selected element. See
Node
doc for details. - Many options that control data loading and saving.
- See libsvgparser's README for parsing benefits.
Limitations
- Because we convert attributes, CDATA, DOCTYPE data to internal representation - we cannot save original content, formatting, etc.
- Encoding should be UTF-8.
- Only most popular attributes are parsed, other stored as strings.
- Compressed SVG (.svgz). You should decompress it by yourself.
- XML text escape is not implemented yet. Parsed text will be stored as is.
- Not supported (mostly rare cases, but still valid by the SVG spec):
-
Complex CSS. Only simple selectors are supported.
-
Whitespacing using a numerical Unicode references, aka
 
. -
Custom namespaces, like:
<g xmlns:s="http://www.w3.org/2000/svg"> <s:circle/> </g>
It will be treated as a non-SVG element.
-
Links to ENTITY not from attributes will lead to
Error::UnsupportedEntity
. Example:&Rect1;
-
- See libsvgparser's README for parsing limitations.
Non-goal
- Implementation of the full SVG spec.
- Animation support.
- Scripting support (via
script
element).
Differences between libsvgdom and SVG spec
- Library follows SVG spec in the data parsing, writing, but not in the tree structure.
- Everything is a
Node
. There are no separatedElementNode
,TextNode
, etc. You still have all the data, but not in the specific struct's. You can check a node type viaNode::node_type()
.
Usage
Dependency: Rust >= 1.13
Add this to your Cargo.toml
:
[]
= "0.5"
See documentation and examples for details.
Build features
All features are enabled by default.
-
parsing
- enables SVG parsing from a string. It enablesFromStream
trait,ParseOptions
struct andDocument::from_data
methods.Disabling it doesn't disable
svgparser
dependency, because we export a lot of types from it.
Performance
There will be no comparisons with other XML parsers since they do not parse SVG data. And no comparisons with other SVG parsers, since there are no such*.
Note that most of the time is spend in a string to number and a number to string conversions.
It's still not as fast as I want, but here are some stats using resave example:
Image | Result |
---|---|
Some huge image** (17.3MiB) | ~850ms/~5500M instructions. |
Big image (1.7MiB) | ~80ms/~500M instructions. |
Average image (324.4KiB) | ~20ms/~89M instructions. |
Small image, like SVG Logo (8.8KiB) | ~0.45ms/~2M instructions. |
* At least I don't know about them.
** It's not direct download links.
Tested on i5-3570k 3.8GHz.
License
libsvgdom is licensed under the MPLv2.0.