libera te tutemet ex inferis

== Overview ==

This package builds a GDK Pixbuf Loader for the SVG format that uses
libsvgtiny:

  https://www.netsurf-browser.org/projects/libsvgtiny/

Why? I'm glad you asked!

GTK (https://www.gtk.org/) is a toolkit that powers many modern
desktop environments and applications. GTK uses an abstraction called
a GdkPixbuf for all of its images. When GTK wants to display an icon,
it first loads that icon into a GdkPixbuf before displaying the result
on the screen. GTK itself knows how to import many common formats like
PNG and JPEG into a GdkPixbuf and can handle those formats
out-of-the-box. The programs that handle the importing of the various
formats are called "pixbuf loaders."

Problem: GTK doesn't know the size of your screen, but it needs to
display icons and images at an appropriate size. How big is that? Good
question: nobody knows. For that reason, GTK makes heavy use of
Scalable Vector Graphics (SVGs). It's much wiser to store one SVG and
scale it to the desired size -- once you know what that is -- than it
would be to store multiple copies of a non-scalable image at each of
the sizes you might need. But, as you may have guessed, GTK itself
doesn't know how to import an SVG into a GdkPixbuf. It doesn't come
with the corresponding pixbuf loader.

The blessed solution to this problem is to use librsvg:

  https://wiki.gnome.org/Projects/LibRsvg

That package builds a pixbuf loader that can be plugged into GTK,
allowing it to import SVG files into a GdkPixbuf, and everything is
great. Or was, until January 3rd, 2017. On that day, librsvg-2.41.0
became the only dependency of GTK that requires Rust, which in turn
requires LLVM. The rest of GTK (and its dependencies) are written in C
or C++. This has several downsides:

  * Rust is big and slow to compile
  * LLVM is big and slow to compile
  * Rust is far less portable than C; it doesn't run on as many CPUs
  * The Rust ecosystem ironically burdens you with easily-avoidable
    security vulnerabilities [0].

It's not feasible to keep the old librsvg around forever, because that
will ALSO result in security vulnerabilities. Which brings us to...

== Why ==

Because if you have a problem with any of the bullet points above,
then you need to replace librsvg if you want to keep using GTK. And,

  * libsvgtiny is written in portable C
  * libsvgtiny is still maintained; there are no open security
    issues
  * libsvgtiny is already packaged on a few distributions as part of
    the netsurf browser

== Caveats ==

The main downside is that libsvgtiny isn't as robust as librsvg. It
renders some things wrong, or a bit uglier than its counterpart. These
are in theory all fixable upstream however, and you will help the
netsurf browser by doing so.

One especially relevant shortcoming is that libsvgtiny doesn't handle
<style> elements within SVG files, and it therefore doesn't encode
GTK's "symbolic SVGs" correctly. Instead of the bright-green layered
abomination that GTK is expecting, we just get the original image
back. This will probably cause problems in corner cases, but it's
still better than nothing.

== Components ==

This package builds three things:

 1. The pixbuf loader, libpixbufloader-libsvgtiny.so. It's a shared
    library that should probably be installed in the directory where
    all your other pixbuf loaders go. This is system-specific, but the
    command

      pkg-config --variable gdk_pixbuf_moduledir gdk-pixbuf-2.0

    should tell you what it is. Afterwards, you have to run
    "gdk-pixbuf-query-loaders --update-cache" to tell GTK about it.
    The man page for gdk-pixbuf-query-loaders mentions some
    environment variables that can be used for more complicated
    installations.

  2. A GTK thumbnailer entry, libsvgtiny.thumbnailer, that tells GTK
     how to create thumbnails of SVG images. (Spoiler: we just run
     gdk-pixbuf-thumbnailer.)

  3. A test program, svg2png, that converts an SVG to a PNG. It does
     this by loading an SVG into a pixbuf, and then saving that pixbuf
     as a PNG. Unless you override GDK_PIXBUF_MODULE_FILE, it will use
     the pixbuf loaders from the system location, so you probably have
     to install libpixbufloader-libsvgtiny.so and update the loader
     cache before svg2png will use it.

== References ==

  [0] https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/