Remove old gtk-doc files

Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/678>

8 files changed, 0 insertions, 1001 deletions

diff --git a/doc/migrating.xml b/doc/migrating.xml
deleted file mode 100644
index dbab592f..00000000
--- a/doc/migrating.xml
+++ /dev/null
@@ -1,454 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<chapter>
-  <title>Migrating from old APIs</title>
-
-  <section id="migrating-from-non-viewport">
-    <title>Migrating from the deprecated API that does not use viewports</title>
-
-    <para>
-      First, some context.  Until librsvg version 2.44, the only way
-      to render an RsvgHandle into a Cairo context was with the
-      functions <function>rsvg_handle_render_cairo(handle, cairo_t)</function> and
-      <function>rsvg_handle_render_cairo_sub(handle, cairo_t, id)</function> —
-      respectively, to render the whole document, and to render a
-      single "layer" from it.  Both functions assumed that the SVG
-      document was to be rendered at its "natural size", or to the
-      size overriden with
-      <function>rsvg_handle_set_size_callback()</function>.  Since the
-      Cairo context can already have an affine transform applied to
-      it, that transform can further change the size of the rendered
-      image.
-    </para>
-
-    <para>
-      Librsvg 2.46 introduced the following functions, designed to replace the <function>render_cairo</function> ones:
-    </para>
-
-    <itemizedlist>
-      <listitem><function>rsvg_handle_render_document()</function> - renders the whole document</listitem>
-      <listitem><function>rsvg_handle_render_layer()</function> - renders a single layer</listitem>
-      <listitem><function>rsvg_handle_render_element()</function> - renders a single element</listitem>
-      <listitem>Plus corresponding functions to get the geometries of the document/layer/element.</listitem>
-    </itemizedlist>
-
-    <para>
-      All of those functions take a <firstterm>viewport</firstterm>
-      argument.  Let's see what this means.  But first, some history.
-    </para>
-
-    <section>
-      <title>Historical note: before librsvg supported viewports</title>
-
-      <para>
-        When librsvg was first written, its API basically consisted of
-        only functions to load an RsvgHandle, plus
-        <function>rsvg_handle_get_pixbuf()</function> to render it
-        directly to a GdkPixbuf image.  Internally the library used
-        libart (a pre-Cairo 2D rendering library), but did not expose
-        it in the public API.
-      </para>
-
-      <para>
-        The only way to specify a size at which to render an
-        RsvgHandle was with
-        <function>rsvg_handle_set_size_callback()</function>, and the
-        callback would run at an unspecified time during
-        <emphasis>loading</emphasis>: when just enough of the SVG
-        document had been loaded to read in the
-        <literal>width/height</literal> attributes of the toplevel
-        <literal>&lt;svg&gt;</literal> element, the callback would let
-        the application override these values with its own desired
-        size.
-      </para>
-
-      <para>
-        Some years later, Cairo was introduced, and it started to
-        replace libart.  Unlike libart, which could only render to
-        in-memory RGBA buffers, Cairo had a notion of "backends": it
-        could render to RGBA buffers, or it could translate its
-        drawing model commands into PDF or PostScript.  In Cairo's
-        terms, one creates a <type>cairo_surface_t</type> of a
-        particular kind (in-memory image surface, PDF surface, EPS
-        surface, etc.), and then a <type>cairo_t</type> context for
-        the surface.  The context is what makes the drawing commands
-        available.
-      </para>
-
-      <para>
-        Being able to render SVG documents directly to PDF or
-        PostScript was clearly attractive, so librsvg's API of
-        <function>rsvg_handle_get_pixbuf()</function> would clearly
-        not be enough.  It would be better to pass a
-        <type>cairo_t</type> for an already-created surface, and have
-        librsvg issue its drawing commands to it.  Then the
-        application would be in control of the surface type, or in the
-        case of GTK widgets, they would already get a
-        <type>cairo_t</type> passed to their drawing functions.
-        Librsvg got modified to export a
-        <function>rsvg_handle_render_cairo(handle,
-        cairo_t)</function>, and then it reimplemented the old
-        <function>rsvg_handle_get_pixbuf()</function> in terms of
-        Cairo.
-      </para>
-
-      <para>
-        At this point, librsvg still kept the notion of rendering SVG
-        documents at their "natural size": the
-        <literal>&lt;svg&gt;</literal> element's
-        <literal>width</literal> and <literal>height</literal>
-        attributes converted to pixels (e.g. converting from
-        <literal>width="5cm"</literal> by using the dots-per-inch
-        value from the RsvgHandle), or if those attributes don't
-        exist, by using the <literal>viewBox</literal> as a pixel
-        size.  The assumption was that if you needed a different size,
-        you could always start by setting the transformation matrix on
-        your <type>cairo_t</type> and then rendering to that.
-      </para>
-    </section>
-
-    <section>
-      <title>The problem with not having viewports</title>
-
-      <para>
-        Most applications which use librsvg to render SVG assets for
-        their user interface generally work in the same way.  For
-        example, to take an SVG icon and render it, they do something
-        like this:
-      </para>
-
-      <orderedlist>
-        <listitem>
-          <para>
-            Create an <type>RsvgHandle</type> by loading it from the SVG icon data.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Ask the <type>RsvgHandle</type> for its dimensions.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Divide the dimensions by the GUI's preferred size for icons.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Scale a Cairo context by the result of the previous step.
-            Translate the Cairo context so the icon will appear at the
-            desired location.
-          </para>
-        </listitem>
-
-        <listitem>
-          <para>
-            Render the <type>RsvgHandle</type> in that Cairo context.
-          </para>
-        </listitem>
-      </orderedlist>
-
-      <para>
-        This is... too much work.  The web world has moved on to using
-        the CSS box model practically everywhere.  To embed an image
-        you specify <emphasis>where</emphasis> and at <emphasis>what
-        size</emphasis> you want to place it, and it gets done
-        automatically.  You actually have to do extra work if you want
-        to do non-standard things like scale an image
-        non-proportionally.
-      </para>
-    </section>
-
-    <section>
-      <title>The new rendering API that uses viewports</title>
-
-      <para>
-        These are the <emphasis>deprecated</emphasis> drawing functions that do not take viewports:
-      </para>
-
-      <programlisting lang="c">
-gboolean rsvg_handle_render_cairo     (RsvgHandle *handle,
-                                       cairo_t    *cr);
-
-gboolean rsvg_handle_render_cairo_sub (RsvgHandle *handle,
-                                       cairo_t    *cr,
-                                       const char *id);
-      </programlisting>
-
-      <para>
-        Starting with librsvg 2.46, the following functions are available:
-      </para>
-
-      <programlisting lang="c">
-typedef struct {
-    double x;
-    double y;
-    double width;
-    double height;
-} RsvgRectangle;
-
-gboolean rsvg_handle_render_document (RsvgHandle           *handle,
-                                      cairo_t              *cr,
-                                      const RsvgRectangle  *viewport,
-                                      GError              **error);
-
-gboolean rsvg_handle_render_layer    (RsvgHandle           *handle,
-                                      cairo_t              *cr,
-                                      const char           *id,
-                                      const RsvgRectangle  *viewport,
-                                      GError              **error);
-
-gboolean rsvg_handle_render_element  (RsvgHandle           *handle,
-                                      cairo_t              *cr,
-                                      const char           *id,
-                                      const RsvgRectangle  *element_viewport,
-                                      GError              **error);
-      </programlisting>
-
-      <para>
-        For brevity we'll omit the <literal>rsvg_handle</literal>
-        namespace prefix, and just talk about the actual function
-        names.  You can see that <function>render_document</function>
-        is basically the same as <function>render_cairo</function>,
-        but it has an extra <parameter>viewport</parameter> argument.
-        The same occurs in <function>render_layer</function> versus
-        <function>render_cairo_sub</function>.
-      </para>
-
-      <para>
-        In both of those cases — <function>render_document</function>
-        and <function>render_layer</function> —, the
-        <parameter>viewport</parameter> argument specifies a rectangle
-        into which the SVG will be positioned and scaled to fit.
-        Consider something like this:
-      </para>
-
-      <programlisting lang="c">
-RsvgRectangle viewport = {
-    .x = 10.0,
-    .y = 20.0,
-    .width = 640.0,
-    .height = 480.0,
-};
-
-rsvg_handle_render_document (handle, cr, &amp;viewport, NULL);
-      </programlisting>
-
-      <para>
-        This is equivalent to first figuring out the scaling factor to
-        make the SVG fit proportionally in 640x480 pixels, then
-        translating the <varname>cr</varname> by (10, 20) pixels, and
-        then calling <function>rsvg_handle_render_cairo</function>.
-        If the SVG has different proportions than the width and height
-        of the rectangle, it will be rendered and centered to fit the
-        rectangle.
-      </para>
-
-      <para>
-        Even better: the old functions to get an SVG's natural
-        dimensions, like
-        <function>rsvg_handle_get_dimensions</function>, returned
-        integers instead of floating-point numbers, so you could not
-        always get an exact fit.  Please use the new functions that
-        take viewports; they will give you easier and better results.
-      </para>
-
-      <note>
-        <para>
-          <function>rsvg_handle_render_element</function> is new in
-          librsvg 2.46.  It extracts a single element from the SVG
-          and renders it scaled to the viewport you specify.  It is
-          different from <function>render_layer</function> (or the
-          old-style <function>render_cairo_sub</function>) in that
-          those ones act as if they rendered the whole document's
-          area, but they only paint the element you specify.
-        </para>
-      </note>
-    </section>
-
-    <section>
-      <title>New API for obtaining an SVG's dimensions</title>
-
-      <para>
-        Per the previous section, you should seldom need to obtain the
-        "natural size" of an SVG document now that you can render it
-        directly into a viewport.  But if you still need to know what
-        the SVG document specifies for its own size, you can use the
-        following functions, depending on the level of detail you
-        require:
-      </para>
-
-      <programlisting lang="c">
-gboolean rsvg_handle_get_intrinsic_size_in_pixels (RsvgHandle *handle,
-                                                   gdouble    *out_width,
-                                                   gdouble    *out_height);
-      </programlisting>
-
-      <para>
-        This returns an exact width and height in floating-point
-        pixels.  <emphasis>You should round up to the next integer</emphasis> if you need to allocate a pixel buffer big enough, to avoid clipping the last column or row of pixels, which may be only partially covered.
-      </para>
-
-      <para>
-        <function>rsvg_handle_get_intrinsic_size_in_pixels</function>
-        works by resolving the <literal>width/height</literal>
-        attributes of the toplevel <literal>&lt;svg&gt;</literal>
-        element against the handle's current DPI and the
-        <literal>font-size</literal> that is defined for the
-        <literal>&lt;svg&gt;</literal> element.
-      </para>
-
-      <para>
-        However, that is only possible if the
-        <literal>width/height</literal> attributes actually exist and
-        are in physical units.  The function will return FALSE if the
-        SVG has no resolvable units, for example if the
-        <literal>width/height</literal> attributes are specified in
-        percentages (e.g. <literal>width="50%"</literal>), since the
-        function has no knowledge of the viewport where you will place
-        the SVG, or if those attributes are not specified.
-      </para>
-
-      <para>
-        The other way of obtaining an SVG's dimensions is to actually
-        query its "intrinsic dimensions", i.e. what is actually
-        specified in the SVG document:
-      </para>
-      
-      <programlisting lang="c">
-typedef enum {
-    RSVG_UNIT_PERCENT,
-    RSVG_UNIT_PX,
-    RSVG_UNIT_EM,
-    RSVG_UNIT_EX,
-    RSVG_UNIT_IN,
-    RSVG_UNIT_CM,
-    RSVG_UNIT_MM,
-    RSVG_UNIT_PT,
-    RSVG_UNIT_PC
-} RsvgUnit;
-
-typedef struct {
-    double   length;
-    RsvgUnit unit;
-} RsvgLength;
-
-void rsvg_handle_get_intrinsic_dimensions (RsvgHandle *handle,
-                                           gboolean   *out_has_width,
-                                           RsvgLength *out_width,
-                                           gboolean   *out_has_height,
-                                           RsvgLength *out_height,
-                                           gboolean   *out_has_viewbox,
-                                           RsvgRectangle *out_viewbox);
-      </programlisting>
-
-      <para>
-        This function will tell you precisely if the toplevel
-        <literal>&lt;svg&gt;</literal> has
-        <literal>width/height</literal> attributes and their values,
-        and also whether it has a <literal>viewBox</literal> and its
-        value.
-      </para>
-
-      <note>
-        <para>
-          Remember that SVGs are <emphasis>scalable</emphasis>.  They
-          are not like raster images which have an exact size in
-          pixels, and which you must always take into account to scale
-          them to a convenient size.  For SVGs, you can just render
-          them to a viewport, and avoid working directly with their
-          size — which is kind of arbitrary, and all that matters is
-          the document's aspect ratio.
-        </para>
-      </note>
-    </section>
-
-    <section>
-      <title>SVGs with no intrinsic dimensions nor aspect ratio</title>
-
-      <para>
-        SVG documents that have none of the <literal>width</literal>,
-        <literal>height</literal>, or <literal>viewBox</literal>
-        attributes are thankfully not very common, but they are hard
-        to deal with: the software cannot immediately know their
-        natural size or aspect ratio, so they cannot be easily scaled
-        to fit within a viewport.  Librsvg has to actually measure the
-        extents of every single element in the SVG document in that
-        case.  If you need to do this by hand, use
-        <function>rsvg_handle_get_geometry_for_layer</function>.
-      </para>
-    </section>
-  </section>
-
-  <section id="migrating-to-geometry-apis">
-    <title>Migrating to the geometry APIs</title>
-
-    <para>
-      Until librsvg 2.44, the available APIs to query the geometry of a layer or element were these:
-    </para>
-
-    <programlisting lang="c">
-struct _RsvgPositionData {
-    int x;
-    int y;
-};
-
-gboolean rsvg_handle_get_position_sub (RsvgHandle       *handle,
-                                       RsvgPositionData *position_data,
-                                       const char       *id);
-
-struct _RsvgDimensionData {
-    int width;
-    int height;
-    gdouble em;
-    gdouble ex;
-};
-
-gboolean rsvg_handle_get_dimensions_sub (RsvgHandle        *handle,
-                                         RsvgDimensionData *dimension_data,
-                                         const char        *id);
-    </programlisting>
-
-    <para>
-      These functions are inconvenient — separate calls to get the
-      position and dimensions —, and also inexact, since they only
-      return integer values, while SVG uses floating-point units.
-    </para>
-
-    <para>
-      Since librsvg 2.46, you can use these functions instead:
-    </para>
-
-    <programlisting lang="c">
-typedef struct {
-    double x;
-    double y;
-    double width;
-    double height;
-} RsvgRectangle;
-
-gboolean rsvg_handle_get_geometry_for_layer (RsvgHandle           *handle,
-                                             const char           *id,
-                                             const RsvgRectangle  *viewport,
-                                             RsvgRectangle        *out_ink_rect,
-                                             RsvgRectangle        *out_logical_rect,
-                                             GError              **error);
-
-gboolean rsvg_handle_get_geometry_for_element (RsvgHandle     *handle,
-                                               const char     *id,
-                                               RsvgRectangle  *out_ink_rect,
-                                               RsvgRectangle  *out_logical_rect,
-                                               GError        **error);
-    </programlisting>
-
-    <para>
-      These functions return exact floating-point values.  They also
-      give you the <firstterm>ink rectangle</firstterm>, or area
-      covered by paint, as well as the <firstterm>logical
-      rectangle</firstterm>, which is the extents of unstroked paths
-      (i.e. just the outlines).
-    </para>
-  </section>
-</chapter>
diff --git a/doc/overview.xml b/doc/overview.xml
deleted file mode 100644
index bc656eed..00000000
--- a/doc/overview.xml
+++ /dev/null
@@ -1,139 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<chapter>
-  <title>Overview of Librsvg's API</title>
-
-  <para>
-    Librsvg is a library for rendering Scalable Vector Graphics files (SVG).
-    Specifically, it can take non-animated, non-scripted SVG documents and render them
-    into a <ulink url="https://www.cairographics.org/">Cairo</ulink> surface.
-    Normally this means an in-memory raster surface, but it could also be any of the
-    other surface types that Cairo supports.
-  </para>
-
-  <para>
-    Librsvg supports many of the graphic features in the <ulink
-    url="https://www.w3.org/TR/SVG/">SVG 1.1</ulink> and <ulink
-    url="https://www.w3.org/TR/SVG2/">SVG2</ulink> specifications.  The main features
-    of SVG that librsvg does not support are the following:
-  </para>
-
-  <itemizedlist>
-    <listitem>
-      <para>
-	Scripting or animation - Librsvg reads SVG data and
-	renders it to a static image.  There is no provision to
-	execute scripts that may control animation parameters.
-      </para>
-    </listitem>
-
-    <listitem>
-      <para>
-	Access to the DOM - Librsvg creates an internal
-	representation of the SVG data, but it does not provide
-	outside access to the resulting Document Object Model
-	(DOM).
-      </para>
-    </listitem>
-
-    <listitem>
-      <para>
-	SVG fonts - Instead, librsvg relies on the system's fonts,
-	particularly those that are available through Cairo/Pango.
-      </para>
-    </listitem>
-  </itemizedlist>
-
-  <para>
-    Librsvg's API is divided into two main parts:  one for loading SVG
-    data and one for rendering it.  In the <emphasis>loading
-    stage</emphasis>, you create an RsvgHandle object from SVG data,
-    which can come from a file or from a stream of bytes.  In the
-    <emphasis>rendering stage</emphasis>, you take an RsvgHandle and ask
-    it to render itself to a Cairo context.
-  </para>
-
-  <section>
-    <title>Loading</title>
-
-    <para>
-      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 GIO stream that will provide SVG data.  At this
-      stage you can get either I/O errors or parsing errors.  If
-      loading completes successfully, the RsvgHandle will be ready for
-      rendering.
-    </para>
-
-    <para>
-      Generally you should use
-      <function>rsvg_handle_new_from_gfile_sync()</function> or
-      <function>rsvg_handle_new_from_stream_sync()</function> to load
-      an SVG document into an RsvgHandle.  There are other convenience
-      functions to load an SVG document, but these two functions let
-      one set the "base file" and the RsvgHandleFlags in a single
-      call.
-    </para>
-  </section>
-
-  <section>
-    <title>Rendering</title>
-
-    <para>
-      Once you have an SVG image loaded into an RsvgHandle, you can
-      render it to a Cairo context any number of times, or to
-      different Cairo contexts, as needed.  As a convenience, you can
-      pick a single element in the SVG by its "id" attribute and
-      render only that element; this is so that sub-elements can be
-      extracted conveniently out of a larger SVG.
-    </para>
-
-    <para>
-      Generally you should use
-      <function>rsvg_handle_render_document()</function> to render the
-      whole SVG document at any size you choose into a Cairo context.
-    </para>
-  </section>
-
-  <section>
-    <title>Example: simple loading and rendering</title>
-
-    <para>
-      The following program loads <filename>hello.svg</filename>,
-      renders it scaled to fit within 640x480 pixels, and writes a
-      <filename>hello.png</filename> file.
-    </para>
-
-    <para>
-      Note the following:
-    </para>
-
-    <itemizedlist>
-      <listitem>
-        <para>
-          <function>rsvg_handle_render_document()</function> will
-          scale the document proportionally to fit the viewport you
-          specify, and it will center the image within that viewport.
-        </para>
-      </listitem>
-
-      <listitem>
-        <para>
-          Librsvg does not paint a background color by default, so in
-          the following example all unfilled areas of the SVG will
-          appear as fully transparent.  If you wish to have a specific
-          background, fill the viewport area yourself before rendering
-          the SVG.
-        </para>
-      </listitem>
-    </itemizedlist>
-
-    <example>
-      <title>Load and render an SVG document as a PNG</title>
-
-      <programlisting>
-        <xi:include href="load-and-render.c" parse="text" xmlns:xi="http://www.w3.org/2001/XInclude"/>
-      </programlisting>
-    </example>
-  </section>
-</chapter>
diff --git a/doc/recommendations.xml b/doc/recommendations.xml
deleted file mode 100644
index 0a298a4f..00000000
--- a/doc/recommendations.xml
+++ /dev/null
@@ -1,145 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<chapter>
-  <title>Recommendations for Applications</title>
-
-  <section id="sizing">
-    <title>How sizing works in SVG</title>
-
-    <para>
-      SVG documents are <emphasis>scalable</emphasis>.  The
-      conventional way to position SVG documents, which comes from the
-      web platform, is to consider a <emphasis>viewport</emphasis> in
-      which to place the SVG document — that is, a rectangular region
-      to where the SVG will be scaled and positioned.
-    </para>
-
-    <para>
-      SVG renderers are supposed to use the viewport provided by the
-      application, plus the SVG document's <literal>width</literal>,
-      <literal>height</literal>, and <literal>viewBox</literal>
-      attributes, to compute the position and size for the rendered
-      document.
-    </para>
-
-    <para>
-      Ideally, the toplevel <literal>&lt;svg&gt;</literal> element of
-      an SVG document will contain <literal>width</literal> and
-      <literal>height</literal> attributes, that indicate the
-      proportions and "natural size" of the document.  When those
-      attributes are present, the SVG renderer can unambiguously
-      figure out the natural aspect ratio of the document, and can
-      also suggest a natural size for the document.  For example,
-      <literal>&lt;svg width="100px" height="50px"&gt;</literal> has
-      a natural size of 100x50 pixels, but it could also be rendered
-      scaled at 200x100 pixels.  Since SVGs are scalable, it is not
-      mandatory to actually use its natural size; it can be scaled
-      arbitrarily.  Of course, it is up to each application how an SVG
-      document will be scaled: a web browser would want to consider
-      the semantics of embedding images in HTML, which may be
-      different from a GUI toolkit loading SVG assets with hard-coded
-      sizes.
-    </para>
-
-    <para>
-      If an SVG document's toplevel <literal>&lt;svg&gt;</literal>
-      element does not have <literal>width</literal> and
-      <literal>height</literal> attributes, then the SVG renderer can
-      try to figure out the document's aspect ratio from the
-      <literal>viewBox</literal> attribute.  For example, there is no natural size for <literal>&lt;svg viewBox="0 0 100 50"&gt;</literal>, but it has a 2:1 (or 100:50) aspect ratio, so it is twice as wide as it is tall.
-    </para>
-
-    <para>
-      If there is no <literal>viewBox</literal> either, then the SVG
-      renderer cannot easily figure out the natural size of the
-      document.  It can either set a 1:1 scaling matrix within the
-      application's viewport and render the SVG there, or it can
-      actually try to compute the size of each object in the SVG
-      document to figure out the size.  The latter is a moderately
-      expensive operation, and can be avoided by having the SVG
-      document specify <literal>width</literal> and
-      <literal>height</literal> attributes.  Try not to have SVG
-      documents that just start with <literal>&lt;svg&gt;</literal>
-      without any of those attributes.
-    </para>
-
-    <section>
-      <title>How librsvg computes document sizes</title>
-
-      <para>
-	Librsvg looks for the <literal>width</literal> and
-	<literal>height</literal> attributes in the toplevel
-	<literal>&lt;svg&gt;</literal> element.  If they are present,
-	librsvg uses them for the "natural" size of the SVG, and this
-	also defines the aspect ratio.  The size has actual units
-	(pixels, centimeters, etc.)  depending on the value of the
-	<literal>width</literal> and <literal>height</literal>
-	attributes.
-      </para>
-
-      <para>
-	If there are no <literal>width</literal> or
-	<literal>height</literal> attributes in the toplevel
-	<literal>&lt;svg&gt;</literal>, librsvg looks for the
-	<literal>viewBox</literal> attribute.  If present, this
-	defines the aspect ratio and a "natural" size in pixels.
-      </para>
-
-      <para>
-	In both cases above (with
-	<literal>width</literal>/<literal>height</literal> and/or
-	<literal>viewBox</literal>), librsvg can determine the
-	"natural" size and aspect ratio of an SVG document immediately
-	after loading.
-      </para>
-
-      <para>
-	Otherwise, if none of those attributes are present in the
-	toplevel <literal>&lt;svg&gt;</literal> element, librsvg must
-	actually compute the coverage of all the graphical elements in
-	the SVG.  This is a moderately expensive operation, and
-	depends on the complexity of the document.
-      </para>
-    </section>
-  </section>
-
-  <section id="recommendations-assets">
-    <title>Recommendations for applications with SVG assets</title>
-
-    <para>
-      Before librsvg 2.46, applications would normally load an SVG
-      asset, then they would query librsvg for the SVG's size,
-      and then they would compute the dimensions of their user
-      interface based on the SVG's size.
-    </para>
-
-    <para>
-      With librsvg 2.46 and later, applications may have an easier
-      time by letting the UI choose whatever size it wants, or by
-      hardcoding a size for SVG assets, and then asking librsvg to
-      render SVG assets at that particular size.  Applications can use
-      <function>rsvg_handle_render_document</function>, which takes
-      a destination viewport, to do this in a single step.
-    </para>
-
-    <para>
-      To extract individual elements from an SVG document and render
-      them in arbitrary locations — for example, to extract a single
-      icon from a document full of icons —, applications can use
-      <function>rsvg_handle_render_element</function>.
-    </para>
-
-    <section>
-      <title>Injecting a user stylesheet</title>
-
-      <para>
-        It is sometimes convenient for applications to inject an extra
-        stylesheet while rendering an SVG document.  You can do this
-        with <function>rsvg_handle_set_stylesheet</function>.  During
-        the CSS cascade, the specified stylesheet will be used with a
-        <ulink
-        url="https://drafts.csswg.org/css-cascade-3/#cascading-origins">"User"
-        origin</ulink>.
-      </para>
-    </section>
-  </section>
-</chapter>
diff --git a/doc/rsvg-docs.xml b/doc/rsvg-docs.xml
deleted file mode 100644
index 6dcab93d..00000000
--- a/doc/rsvg-docs.xml
+++ /dev/null
@@ -1,148 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" ?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
-               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
-  <!ENTITY % local.common.attrib "xmlns:xi  CDATA  #FIXED 'http://www.w3.org/2003/XInclude'">
-  <!ENTITY version SYSTEM "version.xml">
-]>
-<book id="index" xmlns:xi="http://www.w3.org/2003/XInclude">
-  <bookinfo>
-    <title>Librsvg Reference Manual</title>
-    <releaseinfo>
-      For librsvg version &version;
-
-      The latest version of this documentation can be found on-line at the
-      <ulink url="https://developer-old.gnome.org/rsvg/unstable/" role="online-location">GNOME Library</ulink>.
-    </releaseinfo>
-
-    <copyright>
-      <year>2003</year>
-      <year>2004</year>
-      <year>2005</year>
-      <year>2006</year>
-      <year>2007</year>
-      <year>2008</year>
-      <year>2009</year>
-      <holder>Dom Lachowicz</holder>
-    </copyright>
-
-    <copyright>
-      <year>2009</year>
-      <year>2010</year>
-      <holder>Christian Persch</holder>
-    </copyright>
-
-    <copyright>
-      <year>2017</year>
-      <year>2018</year>
-      <year>2019</year>
-      <year>2020</year>
-      <year>2021</year>
-      <holder>Federico Mena Quintero</holder>
-    </copyright>
-  </bookinfo>
-
-  <part id="rsvg">
-    <title>API Reference</title>
-
-    <xi:include href="overview.xml"/>
-    <xi:include href="recommendations.xml"/>
-    <xi:include href="migrating.xml"/>
-
-    <xi:include href="xml/rsvg-handle.xml"/>
-    <xi:include href="xml/rsvg-gio.xml"/>
-    <xi:include href="xml/rsvg-cairo.xml"/>
-    <xi:include href="xml/rsvg-cairo-deprecated.xml"/>
-    <xi:include href="xml/rsvg-pixbuf.xml"/>
-    <xi:include href="xml/rsvg-features.xml"/>
-  </part>
-
-  <chapter xml:id="object-tree">
-    <title>Object Hierarchy</title>
-     <xi:include href="xml/tree_index.sgml"/>
-  </chapter>
-  <index xml:id="api-index-full">
-    <title>API Index</title>
-    <xi:include href="xml/api-index-full.xml"/>
-  </index>
-  <index xml:id="api-index-deprecated" role="deprecated">
-    <title>Index of deprecated symbols</title>
-    <xi:include href="xml/api-index-deprecated.xml"/>
-  </index>
-  <index xml:id="api-index-2-4" role="2.4">
-    <title>Index of new symbols in 2.4</title>
-    <xi:include href="xml/api-index-2.4.xml"/>
-  </index>
-  <index xml:id="api-index-2-8" role="2.8">
-    <title>Index of new symbols in 2.8</title>
-    <xi:include href="xml/api-index-2.8.xml"/>
-  </index>
-  <index xml:id="api-index-2-9" role="2.9">
-    <title>Index of new symbols in 2.9</title>
-    <xi:include href="xml/api-index-2.9.xml"/>
-  </index>
-  <index xml:id="api-index-2-14" role="2.14">
-    <title>Index of new symbols in 2.14</title>
-    <xi:include href="xml/api-index-2.14.xml"/>
-  </index>
-  <index xml:id="api-index-2-22" role="2.22">
-    <title>Index of new symbols in 2.22</title>
-    <xi:include href="xml/api-index-2.22.xml"/>
-  </index>
-  <index xml:id="api-index-2-32" role="2.32">
-    <title>Index of new symbols in 2.32</title>
-    <xi:include href="xml/api-index-2.32.xml"/>
-  </index>
-  <index xml:id="api-index-2-36" role="2.36">
-    <title>Index of new symbols in 2.36</title>
-    <xi:include href="xml/api-index-2.36.xml"/>
-  </index>
-  <index xml:id="api-index-2-46" role="2.46">
-    <title>Index of new symbols in 2.46</title>
-    <xi:include href="xml/api-index-2.46.xml"/>
-  </index>
-  <index xml:id="api-index-2-48" role="2.48">
-    <title>Index of new symbols in 2.48</title>
-    <xi:include href="xml/api-index-2.48.xml"/>
-  </index>
-  <index xml:id="api-index-2-52" role="2.52">
-    <title>Index of new symbols in 2.52</title>
-    <xi:include href="xml/api-index-2.52.xml"/>
-  </index>
-
-  <xi:include href="xml/annotation-glossary.xml"/>
-
-  <appendix xml:id="licence">
-    <title>Licence</title>
-
-    <para>
-      This library is free software; you can redistribute it and/or
-      modify it under the terms of the <citetitle>GNU Lesser General
-      Public License</citetitle> as published by the Free Software
-      Foundation; either version 2.1 of the License, or (at your
-      option) any later version.
-    </para>
-
-    <para>
-      This library is distributed in the hope that it will be useful,
-      but WITHOUT ANY WARRANTY; without even the implied warranty of
-      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-      <citetitle>GNU Lesser General Public License</citetitle> for
-      more details.
-    </para>
-
-    <para>
-      You may obtain a copy of the <citetitle>GNU Lesser General
-      Public Licence</citetitle> from the Free Software Foundation at
-      <ulink url="https://www.gnu.org/licenses/">GNU Licences web
-      site</ulink> or by writing to:
-
-      <address>
-        The Free Software Foundation, Inc.,
-        <street>51 Franklin St</street> – Fifth Floor,
-        <city>Boston</city>, <state>MA</state> <postcode>02110-1301</postcode>,
-        <country>USA</country>
-      </address>
-    </para>
-  </appendix>
-
-</book>
diff --git a/doc/rsvg-overrides.txt b/doc/rsvg-overrides.txt
deleted file mode 100644
index e69de29b..00000000
--- a/doc/rsvg-overrides.txt
+++ /dev/null
diff --git a/doc/rsvg-sections.txt b/doc/rsvg-sections.txt
deleted file mode 100644
index 5690d8f5..00000000
--- a/doc/rsvg-sections.txt
+++ /dev/null
@@ -1,111 +0,0 @@
-<SECTION>
-<FILE>rsvg-handle</FILE>
-<TITLE>RsvgHandle</TITLE>
-RsvgError
-RSVG_ERROR
-rsvg_error_quark
-RsvgHandle
-RsvgHandleClass
-RsvgRectangle
-RsvgLength
-RsvgUnit
-RsvgDimensionData
-RsvgPositionData
-rsvg_set_default_dpi
-rsvg_set_default_dpi_x_y
-rsvg_handle_set_dpi
-rsvg_handle_set_dpi_x_y
-rsvg_handle_new
-rsvg_handle_new_with_flags
-rsvg_handle_write
-rsvg_handle_close
-rsvg_handle_get_base_uri
-rsvg_handle_set_base_uri
-rsvg_handle_get_dimensions
-rsvg_handle_get_dimensions_sub
-rsvg_handle_get_position_sub
-rsvg_handle_has_sub
-rsvg_handle_get_title
-rsvg_handle_get_desc
-rsvg_handle_get_metadata
-rsvg_handle_new_from_data
-rsvg_handle_new_from_file
-rsvg_handle_set_stylesheet
-rsvg_error_get_type
-RSVG_TYPE_ERROR
-
-<SUBSECTION Deprecated>
-rsvg_init
-rsvg_term
-rsvg_cleanup
-rsvg_handle_free
-RsvgSizeFunc
-rsvg_handle_set_size_callback
-
-<SUBSECTION Standard>
-RSVG_HANDLE
-RSVG_IS_HANDLE
-RSVG_TYPE_HANDLE
-rsvg_handle_get_type
-RSVG_HANDLE_CLASS
-RSVG_IS_HANDLE_CLASS
-RSVG_HANDLE_GET_CLASS
-</SECTION>
-
-<SECTION>
-<FILE>rsvg-gio</FILE>
-<TITLE>Using RSVG with GIO</TITLE>
-RsvgHandleFlags
-rsvg_handle_set_base_gfile
-rsvg_handle_read_stream_sync
-rsvg_handle_new_from_gfile_sync
-rsvg_handle_new_from_stream_sync
-
-<SUBSECTION Standard>
-rsvg_handle_flags_get_type
-RSVG_TYPE_HANDLE_FLAGS
-</SECTION>
-
-<SECTION>
-<FILE>rsvg-cairo</FILE>
-<TITLE>Using RSVG with Cairo</TITLE>
-rsvg_handle_get_intrinsic_dimensions
-rsvg_handle_get_intrinsic_size_in_pixels
-rsvg_handle_render_document
-rsvg_handle_get_geometry_for_layer
-rsvg_handle_render_layer
-rsvg_handle_get_geometry_for_element
-rsvg_handle_render_element
-</SECTION>
-
-<SECTION>
-<FILE>rsvg-cairo-deprecated</FILE>
-<TITLE>Deprecated functions to render with Cairo</TITLE>
-rsvg_handle_render_cairo
-rsvg_handle_render_cairo_sub
-</SECTION>
-
-<SECTION>
-<FILE>rsvg-pixbuf</FILE>
-<TITLE>Deprecated functions to render to GdkPixbuf</TITLE>
-rsvg_handle_get_pixbuf
-rsvg_handle_get_pixbuf_sub
-rsvg_pixbuf_from_file
-rsvg_pixbuf_from_file_at_zoom
-rsvg_pixbuf_from_file_at_size
-rsvg_pixbuf_from_file_at_max_size
-rsvg_pixbuf_from_file_at_zoom_with_max
-</SECTION>
-
-<SECTION>
-<FILE>rsvg-features</FILE>
-<TITLE>Version checks</TITLE>
-LIBRSVG_MAJOR_VERSION
-LIBRSVG_MINOR_VERSION
-LIBRSVG_MICRO_VERSION
-LIBRSVG_VERSION
-LIBRSVG_CHECK_VERSION
-rsvg_major_version
-rsvg_minor_version
-rsvg_micro_version
-</SECTION>
diff --git a/doc/rsvg.types b/doc/rsvg.types
deleted file mode 100644
index 298f4d33..00000000
--- a/doc/rsvg.types
+++ /dev/null
@@ -1,3 +0,0 @@
-#include <librsvg/rsvg.h>
-
-rsvg_handle_get_type
diff --git a/doc/version.xml.in b/doc/version.xml.in
deleted file mode 100644
index 27323dad..00000000
--- a/doc/version.xml.in
+++ /dev/null
@@ -1 +0,0 @@
-@VERSION@
\ No newline at end of file