<br><br><div class="gmail_quote">On Dec 15, 2007 1:22 AM, Carl Worth <<a href="mailto:cworth@cworth.org">cworth@cworth.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Sat, 15 Dec 2007 00:05:53 +0100, "Tuom Larsen" wrote:<br>> On Dec 14, 2007 11:13 PM, Carl Worth <<a href="mailto:cworth@cworth.org">cworth@cworth.org</a>> wrote:<br>> > On Fri, 14 Dec 2007 22:47:40 +0100, "Tuom Larsen" wrote:
<br></div><div class="Ih2E3d">> > > - Say an application draws to a window and optionally, if a user would<br>> > > like to, it exports the drawing to PDF. How?<br></div>...<br><div class="Ih2E3d">> But the drawing would be a raster image embeded in PDF, no? Well unless I
<br>> switch to a vector surface target, as you suggest bellow?<br><br></div>I don't follow. How else would you be generating a PDF surface other<br>than using a vector surface target?</blockquote><div><br>I apologize, my bad.
<br>Let's say I'm drawing some random stuff to a window. That has two consequences: I can't re-run the drawing in different surface since it is different every time and from the window I have raster image which I'm using for repainting. Now, if I copy that image surface to PDF surface it's going to be embed as raster image, as I learned yesterday.
<br>For example, I would generate some flowers via stochastic L-system and as I keep going I may like some so much I export them to PDF.<br>On the other hand, I can draw to PDF surface in the first place, save it to a temp file and view it in a window and if I like it I will keep that file.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d"><br>> Yes, I see, thanks. But consider this:<br>> - The drawing is the result of some heavy computation - now it would have to
<br>> run twice.<br><br></div>Or else you cache the result of that heavy compilation somehow. This<br>still looks like an application-specific issue to me. It's not cairo's<br>job to provide data structures to store the results of arbitrary
<br>computation, see?<br><br>Do recall what I said earlier that the application likely has to be<br>able to repaint its window anyway.<br><br>Meanwhile, I don't discount that an exposed meta-surface in cairo<br>would definitely be useful. I still don't think it would solve all
<br>such prolems in applications though. You're still going to want good<br>data application-specific data structures for anything you want to<br>draw.<br><div class="Ih2E3d"><br>> - How to pass the targeting surface through network or pipe? (Simple, you
<br>> [I] don't. You [I] send the drawing source code.)<br>> Please, I certainly don't want to exaggerate.<br><br></div>Again, that looks like something entirely outside of cairo's scope. As<br>I said previously, even if we *did* immediately expose cairo's
<br>meta-surface code we still wouldn't have serialization/deserialization<br>code. And even if we *did* write new serialization/deserialization<br>code based on the current meta-surface implementation it would likely
<br>not be at all efficient, (repeating copies of source surface state,<br>etc.). </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Anything application-specific is going to win hands-down.<br><font color="#888888"><br>-Carl<br></font></blockquote></div><br>Thank you very, very much for your replies and patience!<br><br><br>