[class@Rsvg.

Handle] loads an SVG document into memory.

This is the main entry point into the librsvg library. An [[email protected]] is an object that represents SVG data in memory. Your program creates an [[email protected]] from an SVG file, or from a memory buffer that contains SVG data, or in the most general form, from a `GInputStream` 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:

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

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. All other URL schemes in references require a base URL. For example, this means that if you load an SVG with [ [email protected]_from_data] without calling [[email protected]_base_uri], then any referenced files will not be allowed (e.g. raster images to be loaded from other files will not work).
3. 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.
4. 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).
5. Otherwise, non-`file` schemes are not allowed. For example, librsvg will not load `http` resources, to keep malicious SVG data from "phoning home".
6. 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 [[email protected]].

If you have a `GFile` that stands for an SVG file, you can simply call [[email protected]_from_gfile_sync] to load an [ [email protected]] from it.

Alternatively, if you have a `GInputStream`, you can use [[email protected]_from_stream_sync].

Both of those methods allow specifying a `GCancellable`, 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 [ [email protected]_from_data] and feed that to [[email protected]_from_stream_sync].

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 [[email protected]] from a simple filename or URI with [[email protected]_from_file]. 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 [ [email protected]].

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 [[email protected]] or [ [email protected]_with_flags], and then using [[email protected]] and [[email protected]] 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 [[email protected]_dpi] or [ [email protected]_dpi_x_y] on an [[email protected]] to set the DPI before rendering it.

Rendering

The preferred way to render a whole SVG document is to use [[email protected]_document]. Please see its documentation for details.

API ordering

Due to the way the librsvg API evolved over time, an [[email protected]] 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 [[email protected]] just constructed with [[email protected] ] is not loaded yet, and it does not make sense to call [[email protected]_document] on it just at that point.

The documentation for the available methods in [[email protected]] may mention that a particular method is only callable on a "fully loaded handle". This means either:

* The handle was loaded with [[email protected]] and [[email protected]], and those functions returned no errors.

* The handle was loaded with [[email protected]_stream_sync] and that function returned no errors.

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.