This is the main entry point into the librsvg library. An rsvg.handle.Handle is an
object that represents SVG data in memory. Your program creates an
rsvg.handle.Handle from an SVG file, or from a memory buffer that contains SVG data,
or in the most general form, from a gio.input_stream.InputStream that will provide SVG data.
Librsvg can load SVG images and render them to Cairo surfaces,
using a mixture of SVG's [static mode] and [secure static mode].
Librsvg does not do animation nor scripting, and can load
references to external data only in some situations; see below.
Librsvg supports reading SVG 1.1 data, and is gradually
adding support for features in SVG 2. Librsvg also
supports SVGZ files, which are just an SVG stream compressed with the GZIP algorithm.
The "base file" and resolving references to external files
When you load an SVG, librsvg needs to know the location of the "base file"
for it. This is so that librsvg can determine the location of referenced
entities. For example, say you have an SVG in /foo/bar/foo.svg
and that it has an image element like this:
<image href="resources/foo.png" .../>
In this case, librsvg needs to know the location of the toplevel
/foo/bar/foo.svg so that it can generate the appropriate
reference to /foo/bar/resources/foo.png.
When processing an SVG, librsvg will only load referenced files if they are
in the same directory as the base file, or in a subdirectory of it. That is,
if the base file is /foo/bar/baz.svg, then librsvg will
only try to load referenced files (from SVG's
<image> element, for example, or from content
included through XML entities) if those files are in /foo/bar/<anything> or in /foo/bar/<anything>\/.../<anything>.
This is so that malicious SVG files cannot include files that are in a directory above.
The full set of rules for deciding which URLs may be loaded is as follows;
they are applied in order. A referenced URL will not be loaded as soon as
one of these rules fails:
1. All data: URLs may be loaded. These are sometimes used
to include raster image data, encoded as base-64, directly in an SVG file.
2. URLs with queries ("?") or fragment identifiers ("#") are not allowed.
3. All URL schemes other than data: in references require a base URL. For
example, this means that if you load an SVG with
rsvg.handle.Handle.newFromData without calling rsvg.handle.Handle.setBaseUri,
then any referenced files will not be allowed (e.g. raster images to be
loaded from other files will not work).
4. If referenced URLs are absolute, rather than relative, then they must
have the same scheme as the base URL. For example, if the base URL has a
file scheme, then all URL references inside the SVG must
also have the file scheme, or be relative references which
will be resolved against the base URL.
5. If referenced URLs have a resource scheme, that is,
if they are included into your binary program with GLib's resource
mechanism, they are allowed to be loaded (provided that the base URL is
also a resource, per the previous rule).
6. Otherwise, non-file schemes are not allowed. For
example, librsvg will not load http resources, to keep
malicious SVG data from "phoning home".
7. A relative URL must resolve to the same directory as the base URL, or to
one of its subdirectories. Librsvg will canonicalize filenames, by
removing ".." path components and resolving symbolic links, to decide whether
files meet these conditions.
Loading an SVG with GIO
This is the easiest and most resource-efficient way of loading SVG data into
an rsvg.handle.Handle.
Note that in this case, it is important that you specify the base_file for
the in-memory SVG data. Librsvg uses the base_file to resolve links to
external content, like raster images.
Loading an SVG without GIO
You can load an rsvg.handle.Handle from a simple filename or URI with
rsvg.handle.Handle.newFromFile. Note that this is a blocking operation; there
is no way to cancel it if loading a remote URI takes a long time. Also, note that
this method does not let you specify rsvg.types.HandleFlags.
Otherwise, loading an SVG without GIO is not recommended, since librsvg will
need to buffer your entire data internally before actually being able to
parse it. The deprecated way of doing this is by creating a handle with
rsvg.handle.Handle.new_ or rsvg.handle.Handle.newWithFlags, and then using
rsvg.handle.Handle.write and rsvg.handle.Handle.close to feed the handle with SVG data.
Still, please try to use the GIO stream functions instead.
Resolution of the rendered image (dots per inch, or DPI)
SVG images can contain dimensions like "5cm" or
"2pt" that must be converted from physical units into
device units. To do this, librsvg needs to know the actual dots per inch
(DPI) of your target device. You can call rsvg.handle.Handle.setDpi or
rsvg.handle.Handle.setDpiXY on an rsvg.handle.Handle to set the DPI before rendering
it.
Rendering
The preferred way to render a whole SVG document is to use
rsvg.handle.Handle.renderDocument. Please see its documentation for
details.
API ordering
Due to the way the librsvg API evolved over time, an rsvg.handle.Handle object is available
for use as soon as it is constructed. However, not all of its methods can be
called at any time. For example, an rsvg.handle.Handle just constructed with rsvg.handle.Handle.new_
is not loaded yet, and it does not make sense to call rsvg.handle.Handle.renderDocument on it
just at that point.
The documentation for the available methods in rsvg.handle.Handle may mention that a particular
method is only callable on a "fully loaded handle". This means either:
Before librsvg 2.46, the library did not fully verify that a handle was in a
fully loaded state for the methods that require it. To preserve
compatibility with old code which inadvertently called the API without
checking for errors, or which called some methods outside of the expected
order, librsvg will just emit a g_critical() message in those cases.
New methods introduced in librsvg 2.46 and later will check for the correct
ordering, and panic if they are called out of order. This will abort
the program as if it had a failed assertion.
rsvg.handle.Handle loads an SVG document into memory.
This is the main entry point into the librsvg library. An rsvg.handle.Handle is an object that represents SVG data in memory. Your program creates an rsvg.handle.Handle from an SVG file, or from a memory buffer that contains SVG data, or in the most general form, from a gio.input_stream.InputStream that will provide SVG data.
Librsvg can load SVG images and render them to Cairo surfaces, using a mixture of SVG's [static mode] and [secure static mode]. Librsvg does not do animation nor scripting, and can load references to external data only in some situations; see below.
Librsvg supports reading SVG 1.1 data, and is gradually adding support for features in SVG 2. Librsvg also supports SVGZ files, which are just an SVG stream compressed with the GZIP algorithm.
[static mode]: https://www.w3.org/TR/SVG2/conform.html#static-mode [secure static mode]: https://www.w3.org/TR/SVG2/conform.html#secure-static-mode
The "base file" and resolving references to external files
When you load an SVG, librsvg needs to know the location of the "base file" for it. This is so that librsvg can determine the location of referenced entities. For example, say you have an SVG in /foo/bar/foo.svg and that it has an image element like this:
In this case, librsvg needs to know the location of the toplevel /foo/bar/foo.svg so that it can generate the appropriate reference to /foo/bar/resources/foo.png.
Security and locations of referenced files
When processing an SVG, librsvg will only load referenced files if they are in the same directory as the base file, or in a subdirectory of it. That is, if the base file is /foo/bar/baz.svg, then librsvg will only try to load referenced files (from SVG's <image> element, for example, or from content included through XML entities) if those files are in /foo/bar/<anything> or in /foo/bar/<anything>\/.../<anything>. This is so that malicious SVG files cannot include files that are in a directory above.
The full set of rules for deciding which URLs may be loaded is as follows; they are applied in order. A referenced URL will not be loaded as soon as one of these rules fails:
1. All data: URLs may be loaded. These are sometimes used to include raster image data, encoded as base-64, directly in an SVG file.
2. URLs with queries ("?") or fragment identifiers ("#") are not allowed.
3. All URL schemes other than data: in references require a base URL. For example, this means that if you load an SVG with rsvg.handle.Handle.newFromData without calling rsvg.handle.Handle.setBaseUri, then any referenced files will not be allowed (e.g. raster images to be loaded from other files will not work).
4. If referenced URLs are absolute, rather than relative, then they must have the same scheme as the base URL. For example, if the base URL has a file scheme, then all URL references inside the SVG must also have the file scheme, or be relative references which will be resolved against the base URL.
5. If referenced URLs have a resource scheme, that is, if they are included into your binary program with GLib's resource mechanism, they are allowed to be loaded (provided that the base URL is also a resource, per the previous rule).
6. Otherwise, non-file schemes are not allowed. For example, librsvg will not load http resources, to keep malicious SVG data from "phoning home".
7. A relative URL must resolve to the same directory as the base URL, or to one of its subdirectories. Librsvg will canonicalize filenames, by removing ".." path components and resolving symbolic links, to decide whether files meet these conditions.
Loading an SVG with GIO
This is the easiest and most resource-efficient way of loading SVG data into an rsvg.handle.Handle.
If you have a gio.file.File that stands for an SVG file, you can simply call rsvg.handle.Handle.newFromGfileSync to load an rsvg.handle.Handle from it.
Alternatively, if you have a gio.input_stream.InputStream, you can use rsvg.handle.Handle.newFromStreamSync.
Both of those methods allow specifying a gio.cancellable.Cancellable, so the loading process can be cancelled from another thread.
Loading an SVG from memory
If you already have SVG data in a byte buffer in memory, you can create a memory input stream with gio.memory_input_stream.MemoryInputStream.newFromData and feed that to rsvg.handle.Handle.newFromStreamSync.
Note that in this case, it is important that you specify the base_file for the in-memory SVG data. Librsvg uses the base_file to resolve links to external content, like raster images.
Loading an SVG without GIO
You can load an rsvg.handle.Handle from a simple filename or URI with rsvg.handle.Handle.newFromFile. Note that this is a blocking operation; there is no way to cancel it if loading a remote URI takes a long time. Also, note that this method does not let you specify rsvg.types.HandleFlags.
Otherwise, loading an SVG without GIO is not recommended, since librsvg will need to buffer your entire data internally before actually being able to parse it. The deprecated way of doing this is by creating a handle with rsvg.handle.Handle.new_ or rsvg.handle.Handle.newWithFlags, and then using rsvg.handle.Handle.write and rsvg.handle.Handle.close to feed the handle with SVG data. Still, please try to use the GIO stream functions instead.
Resolution of the rendered image (dots per inch, or DPI)
SVG images can contain dimensions like "5cm" or "2pt" that must be converted from physical units into device units. To do this, librsvg needs to know the actual dots per inch (DPI) of your target device. You can call rsvg.handle.Handle.setDpi or rsvg.handle.Handle.setDpiXY on an rsvg.handle.Handle to set the DPI before rendering it.
Rendering
The preferred way to render a whole SVG document is to use rsvg.handle.Handle.renderDocument. Please see its documentation for details.
API ordering
Due to the way the librsvg API evolved over time, an rsvg.handle.Handle object is available for use as soon as it is constructed. However, not all of its methods can be called at any time. For example, an rsvg.handle.Handle just constructed with rsvg.handle.Handle.new_ is not loaded yet, and it does not make sense to call rsvg.handle.Handle.renderDocument on it just at that point.
The documentation for the available methods in rsvg.handle.Handle may mention that a particular method is only callable on a "fully loaded handle". This means either:
Before librsvg 2.46, the library did not fully verify that a handle was in a fully loaded state for the methods that require it. To preserve compatibility with old code which inadvertently called the API without checking for errors, or which called some methods outside of the expected order, librsvg will just emit a g_critical() message in those cases.
New methods introduced in librsvg 2.46 and later will check for the correct ordering, and panic if they are called out of order. This will abort the program as if it had a failed assertion.