Support SVG Native
SVG Native is at Editor's Draft status in the W3C, and it is of particular interest to people implementing things like SVG emoji fonts ("SVG in OpenType").
Fortunately the spec is mostly about limiting the things that an SVG2 renderer can do; it removes many things that librsvg already does, or that it does poorly, like text support.
I think some key language from the spec is this from the "1.2 Basics" section:
A conforming SVG Native renderer should ignore any functionality requested by a document that is not present in the SVG Native format. If a SVG Native renderer intentionally chooses to honor functionality beyond the SVG Native specification, it must do so in accordance with the [SVG2] specification.
In terms of librsvg, I think this means:
- If librsvg detects that it is rendering an SVG Native document (by file extension? by a specific API? by MIME type?), it could set a flag to ignore features that fall outside of SVG Native.
- If we miss turning off any features from SVG2 that SVG Native explicitly omits, it's not a big deal anyway, and we can fix them gradually.
I'm leaving this issue open as a tracker issue, or an RFC. Some questions to be answered:
-
The pixbuf loader will need to explicitly advertise support for SVG Native file extensions and/or MIME-type. These are not finalized in the spec yet; it links to a github issue about the MIME type. What should we do there?
-
How does librsvg detect an SVG Native document? Just with the
<svg version="1.1" baseAttribute="native">
that the spec mentions? -
There are restrictions on XML features:
No namespaces other than xlink are supported inside an SVG Native document. From the xlink namespace, only href is supported.
A valid SVG Native document must not contain any of the external or internal XML DTD subset.
-
Do we need to tell libxml2 (or whatever XML parser) about these, or should that be handled in librsvg's code?-
-
I think the only major features we lack are support for
var()
andenv()
- see #459