+libera te tutemet ex inferis
+
== Overview ==
This package builds a GDK Pixbuf Loader for the SVG format that uses
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
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 ==
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 ==
-This is a REPLACEMENT for librsvg, and cannot be used alongside it
-(the filenames and mimetypes clash).
-
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
<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.
+ 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
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-libsvgtiny.so and update the loader
+ cache before svg2png will use it.
== References ==
projects / libsvgtiny-pixbuf.git / blobdiff