README

   1 == Overview ==
   2
   3 This package builds a GDK Pixbuf Loader for the SVG format that uses
   4 libsvgtiny:
   5
   6   https://www.netsurf-browser.org/projects/libsvgtiny/
   7
   8 Why? I'm glad you asked!
   9
  10 GTK (https://www.gtk.org/) is a toolkit that powers many modern
  11 desktop environments and applications. GTK uses an abstraction called
  12 a GdkPixbuf for all of its images. When GTK wants to display an icon,
  13 it first loads that icon into a GdkPixbuf before displaying the result
  14 on the screen. GTK itself knows how to import many common formats like
  15 PNG and JPEG into a GdkPixbuf and can handle those formats
  16 out-of-the-box. The programs that handle the importing of the various
  17 formats are called "pixbuf loaders."
  18
  19 Problem: GTK doesn't know the size of your screen, but it needs to
  20 display icons and images at an appropriate size. How big is that? Good
  21 question: nobody knows. For that reason, GTK makes heavy use of
  22 Scalable Vector Graphics (SVGs). It's much wiser to store one SVG and
  23 scale it to the desired size -- once you know what that is -- than it
  24 would be to store multiple copies of a non-scalable image at each of
  25 the sizes you might need. But, as you may have guessed, GTK itself
  26 doesn't know how to import an SVG into a GdkPixbuf. It doesn't come
  27 with the corresponding pixbuf loader.
  28
  29 The blessed solution to this problem is to use librsvg:
  30
  31   https://wiki.gnome.org/Projects/LibRsvg
  32
  33 That package builds a pixbuf loader that can be plugged into GTK,
  34 allowing it to import SVG files into a GdkPixbuf, and everything is
  35 great. Until January 3rd, 2017. On that day, librsvg-2.41.0 became the
  36 only dependency of GTK that requires Rust, which in turn requires
  37 LLVM. The rest of GTK (and its dependencies) are written in C or
  38 C++. This has several downsides:
  39
  40   * Rust is big and slow to compile
  41   * LLVM is big and slow to compile
  42   * Rust is far less portable than C; it doesn't run on as many CPUs
  43   * The Rust ecosystem ironically burdens you with easily-avoidable
  44     security vulnerabilities [0].
  45
  46 It's not feasible to keep the old librsvg around forever, because that
  47 will *also* result in security vulnerabilities. Which brings us to...
  48
  49 == Why ==
  50
  51 Because if you have a problem with any of the bullet points above,
  52 then you need to replace librsvg if you want to keep using GTK. And,
  53
  54   * libsvgtiny is written in portable C
  55   * libsvgtiny is actively maintained
  56   * libsvgtiny is already packaged on a few distributions as part of the
  57     netsurf browser
  58
  59 == Caveats ==
  60
  61 This is a REPLACEMENT for librsvg, and cannot be used alongside it
  62 (the filenames and mimetypes clash).
  63
  64 The main downside is that libsvgtiny isn't as robust as librsvg. It
  65 renders some things wrong, or a bit uglier than its counterpart. These
  66 are in theory all fixable upstream however, and you will help the
  67 netsurf browser by doing so. Regardless, it more or less works.
  68
  69 == Components ==
  70
  71 This package builds three things:
  72
  73  1. The pixbuf loader, libpixbufloader-svg.so. It's a shared library
  74     that should be installed in your GDK_PIXBUF_MODULEDIR. Afterwards,
  75     you have to run "gdk-pixbuf-query-loaders --update-cache" to tell
  76     GTK about it.
  77
  78   2. A GTK thumbnailer entry, libsvgtiny.thumbnailer, that tells GTK
  79      how to create thumbnails of SVG images. (Spoiler: we just run
  80      gdk-pixbuf-thumbnailer.)
  81
  82   3. A test program, svg2png, that converts an SVG to a PNG. It does
  83      this by loading an SVG into a pixbuf, and then saving that pixbuf
  84      as a PNG. **It uses the pixbuf loaders from the live filesystem**
  85      so you have to install libpixbufloader-svg.so and update the
  86      loader cache before svg2png will use it.
  87
  88 == References ==
  89
  90   [0] https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/