[cairo] Observations from a newb

[Donn]

> Yes and no. You can use the SVG data to do the path creation data.
> Extracting data about how to render the paths is much more difficult, here
> come things like CSS (cascading style sheets into play)
> There exist also SVG elements for e.g. groups, transformations etc.
> Handling all these is rather complex, that's why there exist so free
> solution for all of this yet.
It does seem a pity to have to create yet another format, but I totally see 
your point.

> That's where the "service level API" or "meta surface" comes into play.
> Some surfaces  (SVG, PS, PDF I think) can work with low level events like
> "moveto(10,10)" and output these events as valid SVG (i.e. a "10 10 M"
> string). As a side effect these surfaces can be used as a vector pattern
> (in order to be able to write these events, they have to be able to record
> and replay these events)
Okay - it sounds like a closed loop really. You have cairo in a bubble and 
within that you can create PDF/SVG "surfaces" that retain their vectoriness 
and can reflect back into sources. But you can't seem to get external SVG/PDF 
like things into the bubble in the first place. (Just my newb guess)

A route *in* seems to be what we are thinking about.

 I say it would be ideal to spool (at least) pure SVG in because we at least 
have the wonderful Inkscape project to create the graphics with. You opt for 
an intermediate grammar of your own that can be input. How you get a complex 
drawing drawn in the first place is the challenge. An obvious route is 
another parser: SVG --> Yourformat --> Cairo input, kind of makes sense.

\d