Re: Level of Support; general questions

Hi Andy,

> * I would want to try to reduce any dependencies on external libraries
> if at all possible.

librsvg has its share of external dependencies. Pruning those down
will be a modest challenge, but it's a long overdue task.

> * Possible changes to configure/make to allow cross-compiling.

I don't think that this is needed. People cross-compile it for win32
and embedded targets all the time.

> * I won't be using Gnome, so any changes I would make wouldn't be
> testable (by me) for Gnome.

If you manage to slip a patch past me that breaks the ARGB->RGBA
conversion function or the function that loads a byte buffer from a
URI, I'll eat my hat...

> * My requirements are to support close to a full feature set.
> Specifically, addition of animation, DOM, and scripting support.

That's certainly a non-trivial amount of work.

> First off--is there any open source project that more closely matches
> what I'm trying to do above?  I suspect not.  However, to me librsvg
> seems as if it has been relatively stagnant for a while.  So if there's
> something newer that's being actively developed on, I'd want to consider
> that seriously instead of invest what could be quite a bit of time in
> bringing this project up to snuff.

WebKit's SVG backend might be what you're looking for. I have to say
that I resent the implication that librsvg isn't "up to snuff" for
what its intended audience is.

> * Documenting what versions of what (SVG Tiny/Basic/Full, 1.0/1.1/1.2)
> are being supported.

Much of the SVG 1.1 static spec is implemented, as well as a few parts
of the SVG 1.2 static spec. Text handling is known to be deficient.

> * Full unit teseting for all supported features.

Emmanuel has an excellent set of regression tests in SVN. It covers
the SVG 1.1 static spec and many bugs reported against the product
over time. I'm not sure that unit tests have much (if any) value here.

Most of the divergences from the SVG 1.1 reference images are related
to text handling, underspecified specifications/ambiguities, and not
having particular fonts installed locally.

> * Moving todo list into SourceForge for task management.

Why?

> * Enabling Sourceforge bug list and/or feature wish list.

Why? Bugzilla is @ gnome.org.

> * Moving project from CVS into SVN?

It's in SVN already.

> * More generic support for rasterization layer (not necessarily fixed to
> Gnome pixmaps or Cairo).

Cairo is librsvg's rasterization layer abstraction. It's quite robust,
quite generic, and supports more output formats than one can shake a
proverbial stick at. It doesn't have any dependencies beyond libc and
libpng (and the cairo authors consider the latter dependency to be an
expedient mistake), other than the ones you explicitly wish it to
have. Adding new backends to cairo is relatively trivial.

> And then of course after moving more of the project infrastructure into
> Sourceforge, I would start adding the features I need and/or shoring up
> what's there. Does this sound like work the team would want?  Or should
> I try to find another project and/or fork this one?

"Of course".

I'm concerned that you've suggested such radical changes to the
project without explaining your rationale.

I'm not trying to scare you away. $deity knows that librsvg could use
some more attention. I just want to understand where you're coming
from.

Best regards,
Dom

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/