On Wed, 17 Nov 2004 20:15:19 -0500, MenTaLguY wrote:
I think the biggest thing Inkscape can bring to the table up front is architectural "lessons learned".
And I think that will be greatly appreciated.
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.
These synchronization issues don't sound like much fun. I can imagine that if you care about round-tripping the XML or something that you would need the dual representations. But for a "simple" dynamic SVG viewer I can't see why we would want two trees.
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.
That kind of approach sounds great.
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.
Wise plan. Maybe we should start collecting post-mortem data from those in the know. I can definitely start talking to gnome people. If everyone agrees that their current canvas needs to be chucked, then we should find some common place to start planning a new one.
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.
We actually do have a GDI+ surface type. Stuart Parmenter has been working on this for a couple months and it just barely went into CVS, (2004-11-12). I don't know when our CVS server will appear again, (hopefully very soon), but in the meantime, here are the two new files that he added:
http://cworth.org/~cworth/tmp/cairo_gdip_font.cpp http://cworth.org/~cworth/tmp/cairo_gdip_surface.cpp
As for the image surface, cairo just draws to *your* buffer that you hand it with cairo_set_target_image. Maybe the problem there is that it's too obvious how to get at the data. ;-)
And, yes, someday (soon) we will address the missing documentation issue...
-Carl