[cairo] Observations from a newb
donn.ingle at gmail.com
Fri Nov 9 01:33:21 PST 2007
> 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
> 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.
More information about the cairo