On Fri, Jul 29, 2005 at 03:11:14PM +0200, Tarjei Knapstad wrote:
I see, will take a look at what's done and not and hopefully start playing around with the code some more during the weekend.
Great, make sure to pop onto IRC to ask questions.
I'll have to plead ignorance here for now, but I assume that Inkscape documents are represented as SVG throughout?
There is an XML parser that reads the SVG and creates a big tree of all the elements, their styles, referenced elements, etc. etc. This tree is called the "Repr" (I think it's short for Representation).
This Repr is used as the "input" to the renderer that generates the rasterized version for the screen or PNG, and it can be interactively tweaked, altered, and so forth. The undo system is also tied in with the Repr to allow "journalling" of changes so the user can easily go backwards or forwards in the change history. The Repr can also be run through a command to write it out as SVG.
Thus, the SVG is represented in memory in a fashion directly analogous to the SVG file, but it's not literally SVG at that point, but rather an expanded structure that is easier to interact with programmatically.
I had a look at the Cairo CVS repo last night, and noticed that there's a libsvg-cairo which renderes SVG documents (either from disk or from a buffer) through Cairo. Is this something you've had a look at? One possible problem that springs to mind is that this library is not flexible enough to handle realtime editing of SVG docs, but this is just speculation at the moment...
Yes, I've looked at this, although not recently. I think it is definitely worth additional study. When I looked at it a year ago it was not in a form that we could use in Inkscape except as an example of one way to hook SVG and cairo together, because it didn't allow for interactive, dynamic updating of the view. However, much has changed in recent months and I think it needs to be reexamined. I'd love it if we could reuse it instead of creating our own svg wrapper on Cairo, but since Inkscape's needs here are pretty intensive it may make more sense for us to have the wrapper code inside Inkscape where we can work on it directly.
However, this is all just my guesses from very brief looks at all this code, I think it will really require someone to experiment with all these components to see what can be done with them.
Bryce