On Tue, 4 Jan 2005, Derek P. Moore wrote:
As for making Inkscape's renderer a dynamic gdk-pixbuf loader... I don't imagine it would be too difficult. Personally, I wouldn't know where to start. But, Bulia, you may know enough about Inkscape's renderer to do it.
Basically it would mean turning Inkscape's renderer into a shared library (which might benefit Inkscape along the way). You'd also have to write a 'loader' shared object and an 'engine' shared object for GTK+ to use Inkscape's renderer library (they go into /usr/lib/gtk-2.0/2.4.0/engines/ and /usr/lib/gtk-2.0/2.4.0/loaders/).
If it's possible to be done, it could help Inkscape, GTK+, and GNOME all at once. It could help Inkscape by making the renderer's interface more clean and modular. It could help GTK+/GNOME by providing a higher quality alternative to librsvg, which would become more and more viable as Inkscape's renderer speeds up and becomes more efficient. And it could help the rest of the Free Software world by providing a very high quality SVG rendering library to reuse.
An arguably better approach may be to do the above, but base it off of Cairo instead of Inkscape's renderer. Cairo is also being woven in at the X.org level so my guess is that long term it will become the preferred SVG renderer, over librsvg.
We've talked seriously about eventually replacing Inkscape's renderer with Cairo one day, so it would be in keeping with our plans. It has a well defined API, and is broken up into multiple lib's, allowing us to only load in the specific components required.
The downside is that the time for adding Cairo as a dependency for Inkscape still appears to be in the future. More work is required both on Cairo (speed/capability improvements) and on Inkscape (to be able to hook into alternate renderers). So it may be a little premature to consider it for something like icon rendering. However, it could probably be the most efficient and effective use of effort.
Bryce