README: wording tweaks

diff --git a/README b/README
index fde583815295a429047442e9b1c8cacbfcf89a88..de48400eb95914d497a97e8d7be1d05b06ff8255 100644 (file)
--- a/README
+++ b/README
@@ -1,3 +1,5 @@
+libera te tutemet ex inferis
+
 == Overview ==
 
 This package builds a GDK Pixbuf Loader for the SVG format that uses
@@ -32,10 +34,10 @@ The blessed solution to this problem is to use 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. 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:
+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
@@ -44,7 +46,7 @@ C++. This has several downsides:
     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...
+will ALSO result in security vulnerabilities. Which brings us to...
 
 == Why ==
 
@@ -52,9 +54,10 @@ 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 actively maintained
-  * libsvgtiny is already packaged on a few distributions as part of the
-    netsurf browser
+  * 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 ==
 
@@ -70,17 +73,24 @@ 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 all sorts of problems in corner cases,
-but it's still better than nothing.
+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-svg.so. It's a shared library
-    that should be installed in your GDK_PIXBUF_MODULEDIR. Afterwards,
-    you have to run "gdk-pixbuf-query-loaders --update-cache" to tell
-    GTK about it.
+    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
@@ -88,9 +98,10 @@ This package builds three things:
 
   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. **It uses the pixbuf loaders from the live filesystem**
-     so you have to install libpixbufloader-svg.so and update the
-     loader cache before svg2png will use it.
+     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-svg.so and update the loader cache
+     before svg2png will use it.
 
 == References ==