[cairo-commit] [cairo-www] src/summit

[Carl Worth]

 src/summit/2008/notes.mdwn |   57 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)

New commits:
commit 30c227783431a1834ba42b08ff927967dffe2812
Author: Carl Worth <cworth at cworth.org>
Date:   Tue Aug 26 16:07:17 2008 -0700

    More live notes

diff --git a/src/summit/2008/notes.mdwn b/src/summit/2008/notes.mdwn
index 7a42cb6..68e5319 100644
--- a/src/summit/2008/notes.mdwn
+++ b/src/summit/2008/notes.mdwn
@@ -280,3 +280,60 @@ back into both unstable and stable easier.
 
 Automated Testing WITH feedback important part of keeping project
 management rolling.
+
+15:00 Printing/PDF
+------------------
+
+Adrian: The next feature we need is to avoid re-implementing the same
+image multiple times. Also, there are miles and miles of PDF
+specification without cairo API. We probably don't want to implement
+all of that. One idea is a generic API for inserting an arbitrary PDF
+object, allowing us to offload the work to an external
+library---that's especially useful for the non-graphical portions of
+PDF. As for graphical stuff, probbaly the only piece we're really
+missing is mesh gradients.
+
+Vlad: To what extent is cairo the be-all-and-end-all solution for PDF
+generation? Where do we draw the line?
+
+Adrian: It's a hard question to answer. No matter what we generate,
+it's always easy for users to want one more feature. Another idea
+rather than having API for the application to shove objects into
+cairo's PDF file would be for cairo to instead shove objects into the
+application's PDF file, (or that of some external PDF-generating
+library).
+
+Adrian: Another topic is metadata for PDF, (author, creator, date,
+etc.). There are basically three ideas:
+
+  1. PDF-specific API
+
+  2. Generic API for any surface type
+
+  3. Offload to one of the approaches above for external PDF library.
+
+[Good consensus about option 2.]
+
+The API should be very generic, and perhaps even more generic than
+add_metadata. It could be even "add_property", and could even control
+things like compression for PDF etc. A good "hack session" topic would
+be to draft up this "property" API.
+
+Adrian: JPEG embedding---I've got some code already, but what we have
+to agree on is the API:
+
+  1. A setter on a surface/pattern to provide the JPEG image data
+
+  2. cairo_surface_create_from_jpeg (like cairo_surface_create_from_png)
+
+Consensus that option #1 is better. And it should be on the pattern
+rather than the surface, and that it should allow for other data types
+rather than just JPEG, (can accept a mime type and the blob of
+data). So maybe something like this:
+
+	cairo_pattern_set_image_data (cairo_pattern_t *pattern,
+				      const char *mimetype,
+				      unsigned char *data,
+				      unsigned int length);
+
+[Discussion of mesh gradients.]