Proposal talk:Librsvg development funding

From Strategic Planning

Alternative approach

Batik renderer

An alternative approach to improving SVG quality would be to use a better renderer. Java based Batik, which undoubtedly would provide a much superior quality, has been discussed for the last time in 2006: meta:SVG image support#Current implementation came to the conclusion that it was too slow. Unfortunately, this was apparently tested only with stand-alone commands, which means starting up the Java VM for every convert.

The same year someone started a Batik Server project. Noone reacted, and his efforts ended with a version 0.1. This weekend, I have been doing some preliminary comparisons of rendering times between rsvg and Batik using the server, and my finding is that at least Batik can claim not to be as hopelessly outperfomed as it originally seemed to be.

Thus, it should be considered not to fund the improvement of librsvg, but to develop a useable Batik server or daemon. --Hk kng 18:24, 9 August 2009 (UTC)[reply]


Why is it again that we're not just using Inkscape?

Inkscape works and is actively maintained. librsvg doesn't and isn't. Jheald 10:43, 15 March 2010 (UTC)[reply]

I think that replacing the RSVG renderer in wiki with the inkscape one could potentially make sense. A few points
  1. It would seem to be easier to code in inkscape as a replacement, than to delve into RSVG to fix bugs. I.e. more people can do the job. It might be easier too. Is there any estimate on the workload to rip and replace RSVG with something else?
  2. Is inkscape faster/slower than RSVG? 14:51, 15 March 2010 (UTC)[reply]

Don't you mean Cairo?

Didn't Inkscape recently give up on its homegrown libnr and now justs links to libcairo for all its rendering? For that matter, the major browsers not from Microsoft (like Firefox, Safari/Webkit) use libcairo for their rendering. And unlike librsvg, which had its last release back in 2005, Cairo is still very active. And as a bonus Cairo and Pango have been integrated which should to fix almost all those pesky SVG font bugs -- KelleyCook 16:07, 6 July 2010 (UTC)[reply]

No they mean inkview

Yes, and sorry for spamming the bugs before looking here and finding the same idea. Inkview is much less heavyweight than Batik, BTw. -- 16:50, 12 March 2012 (UTC)[reply]

Option to turn off renderer

It would also be nice to have an option in Special:Preferences to disable the rendering to a pixel graphic (just like you can disable TeX-rendering) if you have a browser which supports SVG-rendering. Matthias M. 07:06, 10 August 2009 (UTC)[reply]

+ I would also like to see the possibility to completely deactivate the automatic rendering of SVG-files into PNG-files. Because browsers like Opera can handle SVG-files as good as any other image file. -- 22:01, 11 August 2009 (UTC)[reply]
+ Great idea. The next step would be allowing svg in wikicode! 05:16, 14 August 2009 (UTC)[reply]
This is a great idea and should be split off into a new section (and/or put into a bugzilla filing).
Brion Vibber just posted 12 days ago in bug #8566 (Thumbnail rendering of SVGs broken) "Assigning SVG bugs to Ariel -- need a cleanup pass to see what's fixed up by a librsvg upgrade, what can be resolved with fixes to our font configuration, what can be fixed on our end, and what still needs to be pushed upstream."
This experimental extension seems to exist for just this purpose. Grenavitar 08:04, 15 August 2009 (UTC)[reply]
Proposal:Inline SVG preference is the proposal for this I created. Grenavitar 08:17, 15 August 2009 (UTC)[reply]


This'll make SVGs a lot more worthwhile. Currently the second biggest problem is that SVGs sometimes get screwed up by the renderer, which makes the effort of producing them wasted. A correction of the bugs'll make the en:WP:GL/I'ers happy. 19:39, 16 August 2009 (UTC)[reply]

Leverage GSoC?

Google Summer of Code provides stipends ($4,500) to students working on FLOSS code. They have worked through and understood many of the problems of funding open source work. Improvements/bugfixes to SVG libraries could be made to happen as one GSoC project. Whilst most GSoC projects are about writing new software features, nothing prevents a GSoC project being a bug fixing project.

The key is to find a mentor - someone who already works with the SVG code, willing to mentor a student - but who does not have enough spare time themselves to fix the problems in the code.

Finding an organisation that participates in GSoC to be the mentoring organisation is easier. Inkscape have participated in previous years, and would likely be open to such an approach.


Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 00:12, 3 September 2009 (UTC)[reply]

The impact would be: a lot less bugs in SVG thumbnails... People are encouraged to upload/deal with SVG vectorial pictures. Kelson 11:24, 21 April 2010 (UTC)[reply]


Currently, a dev. is working hard to fix issues in librsvg : . IMO, his activity should be encouraged anyhow. Kelson 11:24, 21 April 2010 (UTC)[reply]