Cross-platform svg support

[Tor Lillqvist <tml iki fi>]

Eugene Morozov writes:
 > Unfortunately, there's no support for SVG in win32 version of GTK.

There is precisely as much "support" for SVG in GTK on Win32 as there
is on X11 (Unix): None.

The "support" on Unix comes from an independently developed
dynamically loaded module, that is registerd in the gdk-pixbuf.loaders
file. At least in OpenSUSE and Ubuntu, the svg loader is in a
different package than GTK+.

Nothing prevents somebody for distributing a similar librsvg package
for Win32. One slight problem would be to think of a way to make sure
the gdk-pixbuf-query-loaders program is executed to update the
gdk-pixbuf.loaders file after installing the librsvg package.

In case of bundle-everything -type executable installers, that is of
course not a problem. (Personally I don't use such installers, as they
give so little control and bundle stuff from different sources and
with different release schedules together. But for end-users, they
probably are the only realistic alternative.)

In case of "dumb" zipfile-type distributions, there would have to be
instructions to the end-user to run gdk-pixbuf-query-loaders manually.

Unfortunately there is no middle ground. There is no intelligent
package management system a'la RPM or dpkg for Windows. At least I
haven't found any. (If there was, I would stop distributing zipfiles
and switch. Executable installers for end-users could then be
essentially wrappers around the package management system.)

Porting either RPM or dpkg is feasible, but not easy. Both have their
problems. RPM is huge, dpkg's code is written in an, eh, "interesting"
style, and performs some very Unixish fork/dup/exec acrobatics. 

To really be usable on Windows, such a port (of either) would have to
be enhanced to fill one essential requirement: freely end-user
selectable installation prefixes. Using fixed configure-time paths
like on Unix is *not* acceptable on Windows.

Another requirement is high on my list, too: It should be possible to
install different (conflicting) versions of the same package in
different prefixes, and still have both instances recorded in the same
package management database. These different versions of the same
package should then both be able to depend on some common lower-level
package, of which (one or several) versions are installed in yet a
third (fourth, etc) prefix. (I.e. it should be possible to have both
gtk+-2.8.3 and gtk+-2.6.10 installed, both depending on the same
installed version (or one of several compatible installed versions) of
libpng. Etc.

But I have been digressing far from the subject now, better stop...

--tml