[cairo] surface SVG to current context

[Carl Worth]

On Fri, 14 Dec 2007 13:03:01 +0200, Donn wrote:
> So, it seems the only purpose for having a "Surface" as an input to the Source
> is for feedback from a push/pop_group.

Not really. You can draw to any surface, and then use that surface as
a source without any group being involved.

> > A cairo surface is output only. The fact that it can be used as input is
> > purely coincidental (and is part of the non-obviousness of cairo)
> That's what I'm trying to clear-up. I wait for snippets of clarity from this
> list like a parched man in the Kalahari! Thanks for your info!

A surface is not output only---you can do cairo_set_source_surface or
cairo_pattern_create_for_surface to read from a surface. But you can't
use cairo directly to parse an SVG or PDF file.

> > What I still think is missing is some way to serialize / deserialize a
> > stream of cairo commands into a file, which is part of cairo, basically a
> > meta file system.
> Carl has mentioned this. I can't really understand it all. In my mind I see
> that "reading" an SVG file and "writing" an SVG file are two sides of the
> same (horribly complex, no doubt) coin. It's all about parsing XML and then
> element strings. So, I'll wait and see what this meta file stuff is all
> about.

Reading and writing a file format may seem like obviously-paired
functionality from an application's point of view. But if you look at
what it actually takes to implement the two, it's vastly different.

For example, the output side is not complex at all---one only need
support what one is interested in. For example, here's one line of C
code that produces what I think is an entirely standards-conformant
SVG file:

	printf ("<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
		"<svg xmlns=\"http://www.w3.org/2000/svg\" "
		"width=\"20\" height=\"20\">\n"
		"  <path d=\"M5,5 L15,5 L15,15 Z\" />\n"
		"</svg>\n");

Now, imagine how many more lines of C code it might require to parse
any given standards-conformant SVG file. The complexity is definitely
of the size of cairo itself, and that's why we have separate libraries
like librsvg for SVG parsing and poppler for PDF parsing.

Now, if your canvas implementation is happy to depend on cairo and
those other libraries, then you might definitely make PDF and SVG
files be first-class objects and make the reading/writing of these
files be perfectly symmetric. That would definitely be a good
thing---it's just not going to happen within cairo itself.

As for meta-surfaces, the concept there is for users to be able to
capture a sequence of drawing operations in a "vector" form and then
replay them later. It doesn't necessarily mean that we'll provide any
code to do serialization and deserialization. For example, we have a
meta-surface implementation in cairo already, and it's basically just
a single API question about how to best expose it. But serializing and
deserializing would require a bunch of additional code that doesn't
exist now.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20071214/eec3f5a5/attachment.pgp