If one looks at the binding specs of the SVG DOM (which are quite large) and the associated IDL specs, it looks like maybe even libxml is not sufficient to the task. From what I have seen, it looks like XercesC++ has the most "correct" DOM implementation, and would be best for extending into the SVG-DOM world.
It just seems to me, in my poor IMHO, that the DOM design really needs to be clean and proper from the ground up, and not just be a set of thin and buggy wrappers.
Bob
MenTaLguY wrote:
On Wed, 2004-11-17 at 13:15, Carl Worth wrote:
For a simple renderer, something like the SPObject/SPRepr split is likely to be severe overkill.
A simple renderer, we have already in libsvg-cairo.
Beyond that, people are interested in a standalone, cairo-based SVG viewer with support for dynamic HTML. Libsvg-cairo is not up to that task. What I don't know is if it makes sense to start trying to build it up, or if we should instead extract the SVG guts from something else, (such as sodipodi).
Some of it is going to have to be built independently.
Sodipodi has a lot of deep architectural issues that need fixing; I don't think you would find it a good choice.
Inkscape, in turn, inherited the same deficiencies and we're far from getting them all fixed yet. It also uses C++ and has some additional dependencies that might be undesirable for a more general library.
I think the biggest thing Inkscape can bring to the table up front is architectural "lessons learned".
If you want dynamic HTML (by which I assume you mean DOM), my feeling is you'll need to do something similar to what Sodipodi and Inkscape do: we have a pre-chewed "semantic" layer a bit like librsvg's, and then a raw XML/CSS abstract syntax tree underneath it, with protocols for synchronizing changes between the two.
I hate reinventing wheels, though. What I hope is that we can take designs prototyped and tested in Inkscape, contribute them to cairo/f.d.o as components of more portable C libraries, and adopt those libraries ourselves to the extent practical.
Sort of peeling layers off the bottom as we go, I guess.
I'd like to see a good "standard" retained-mode API built on top of cairo. It should be the kind of thing that might make it almost trivial to write a dynamic SVG viewer as mentioned above. It could also make a good replacement for libgnome-canvas, (something that Gnome seems to be grappling about for right now).
My impression from lurking on Rosegarden lists and those of other KDE projects is that the state of the generic QT canvas isn't much better.
You know, actually, it's almost like there's a curse on general-purpose canvas libraries... It might be helpful to examine why such projects seem to keep failing. I have a feeling mistakes in that area are easy to repeat.
As for making this portable, (ie. for Gnome and KDE), I don't know if it should talk to one of the existing event-loop integration projects, or if it should export its own hooks for plugging in an event loop, (ie. perhaps libevent compatible or something). Someone who better knows the toolkits and integration projects should be consulted there.
Based on my experiences with Inkscape and Sodipodi, trying to treat every node in the display graph as a "mini-widget" with event dispatching is a mistake for broad and deep graphs like those that would correspond to many complex SVG documents.
The important primitives to have in a retained-mode graphics API for graphical interactivity seem to be:
find the first descendant of a specified node matching a predicate (given as a closure), maybe with a choice of traversal strategies
primitives for determining whether a node overlaps with a given shape, maybe with optimized versions for testing against a point+tolerance radius, and against a bounding rectangle
And then you can readily build "mini-widgets" on top of that if need be (potentially as a higher-level library), but you aren't forced to deal with the whole display graph that way.
In the meantime, has anyone played with cairo-based rendering for inkscape? It shouldn't be too hard to get going, (for example, the Scribus guys said they got something working in just one weekend last week).
Me, kind of. I've been experimenting with it a bit offline, and plan to work on it more earnestly during the 0.41 development cycle.
One of the big hurdles is that it would need to work on Win32. As far as I know there is no Win32 GDI surface type, and it's not obvious how to get at the in-memory buffer of a Cairo image surface.
Maybe some of the Win32 Inkscape developers could help with that, though (anyone interested?).
-mental