RsvgHandle loads an SVG document into memory.

This is the main entry point into the librsvg library. An RsvgHandle is an object that represents SVG data in memory. Your program creates an RsvgHandle 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.

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. 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_new_from_data() without calling rsvg_handle_set_base_uri(), 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 RsvgHandle.

If you have a GFile that stands for an SVG file, you can simply call rsvg_handle_new_from_gfile_sync() to load an RsvgHandle from it.

Alternatively, if you have a GInputStream, you can use rsvg_handle_new_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 g_memory_input_stream_new_from_data() and feed that to rsvg_handle_new_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 RsvgHandle from a simple filename or URI with rsvg_handle_new_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 RsvgHandleFlags.

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_new() or rsvg_handle_new_with_flags(), and then using rsvg_handle_write() and rsvg_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_set_dpi() or rsvg_handle_set_dpi_x_y() on an RsvgHandle to set the DPI before rendering it.

Rendering

The preferred way to render a whole SVG document is to use rsvg_handle_render_document(). Please see its documentation for details.

API ordering

Due to the way the librsvg API evolved over time, an RsvgHandle 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 RsvgHandle just constructed with rsvg_handle_new() is not loaded yet, and it does not make sense to call rsvg_handle_render_document() on it just at that point.

The documentation for the available methods in RsvgHandle may mention that a particular method is only callable on a “fully loaded handle”. This means either:

• The handle was loaded with rsvg_handle_write() and rsvg_handle_close(), and those functions returned no errors.

• The handle was loaded with rsvg_handle_read_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.