Package org.gnome.rsvg

Class Handle

java.lang.Object
org.javagi.base.ProxyInstance
org.gnome.gobject.TypeInstance
org.gnome.gobject.GObject
org.gnome.rsvg.Handle
All Implemented Interfaces:
Proxy
@Generated("io.github.jwharm.JavaGI") public class Handle extends GObject
Handle loads an SVG document into memory.

This is the main entry point into the librsvg library. An Handle is an object that represents SVG data in memory. Your program creates an Handle 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.htmlstatic-mode [secure static mode]: https://www.w3.org/TR/SVG2/conform.htmlsecure-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. 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 fromData(byte[]) without calling setBaseUri(java.lang.String), 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. URLs with a file scheme are rejected if they contain a hostname, as in file://hostname/some/directory/foo.svg. Windows UNC paths with a hostname are also rejected. This is to prevent documents from trying to access resources on other machines.

8. 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 Handle.

If you have a GFile that stands for an SVG file, you can simply call fromGfileSync(org.gnome.gio.File, java.util.Set<org.gnome.rsvg.HandleFlags>, org.gnome.gio.Cancellable) to load an Handle from it.

Alternatively, if you have a GInputStream, you can use fromStreamSync(org.gnome.gio.InputStream, org.gnome.gio.File, java.util.Set<org.gnome.rsvg.HandleFlags>, org.gnome.gio.Cancellable).

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 MemoryInputStream.fromData(byte[]) and feed that to fromStreamSync(org.gnome.gio.InputStream, org.gnome.gio.File, java.util.Set<org.gnome.rsvg.HandleFlags>, org.gnome.gio.Cancellable).

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 Handle from a simple filename or URI with fromFile(java.lang.String). 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.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 Handle() or withFlags(java.util.Set<org.gnome.rsvg.HandleFlags>), and then using write(byte[]) and 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 setDpi(double) or setDpiXY(double, double) on an Handle to set the DPI before rendering it.

For historical reasons, the default DPI is 90. Current CSS assumes a default DPI of 96, so you may want to set the DPI of a Handle immediately after creating it with setDpi(double).

Rendering
The preferred way to render a whole SVG document is to use renderDocument(org.freedesktop.cairo.Context, org.gnome.rsvg.Rectangle). Please see its documentation for details.

API ordering
Due to the way the librsvg API evolved over time, an 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 Handle just constructed with Handle() is not loaded yet, and it does not make sense to call renderDocument(org.freedesktop.cairo.Context, org.gnome.rsvg.Rectangle) on it just at that point.

The documentation for the available methods in 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.