[cairo-commit] [cairo-www] 2 commits - src/summit
Carl Worth
cworth at freedesktop.org
Wed Sep 3 07:38:12 PDT 2008
src/summit/2008/notes.mdwn | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
New commits:
commit 58450cc1468094e4080556682db3d6fe4d027885
Merge: aeda31b... c7f67ea...
Author: Carl Worth <cworth at cworth.org>
Date: Wed Sep 3 07:37:33 2008 -0700
Merge branch 'master' of annarchy.freedesktop.org:/srv/cairo.freedesktop.org/wiki
diff --cc src/summit/2008/notes.mdwn
index bc05a4d,5133244..57f5589
--- a/src/summit/2008/notes.mdwn
+++ b/src/summit/2008/notes.mdwn
@@@ -432,10 -432,10 +432,10 @@@ Fixing test-suite failure
Chris and Carl had only a very little time to look at this issue. Carl
is getting 8 failures on the image backend, (which should really
always have 0 failures). Five of these have apparently never passed
-and are related to the LCD_FILTER API, which Carl had already wanted
+and are related to the `LCD_FILTER` API, which Carl had already wanted
to just remove. Behdad agreed grudgingly. The remaining 3 failures
look simply like rasterization differences which Carl didn't track
- down yet.
+ down yet. On that topic, Antoine proposed to work on a smarter image comparison algorithm to avoid these errors. Carl expressed interest in seeing that, and removing the reference images for each individual platform.
Improving image downscaling quality
-----------------------------------
commit aeda31b6ee56f7d93096e16c2921117721bad487
Author: Carl Worth <cworth at cworth.org>
Date: Wed Sep 3 07:37:17 2008 -0700
Protect underscores from MarkDown
diff --git a/src/summit/2008/notes.mdwn b/src/summit/2008/notes.mdwn
index d6108dd..bc05a4d 100644
--- a/src/summit/2008/notes.mdwn
+++ b/src/summit/2008/notes.mdwn
@@ -200,7 +200,7 @@ Behdad: Review of stuff since 1.6:
http://cairographics.org/news/cairo-1.7.2
[Carl got too involved in this discussion to keep good notes. Most of
-the new API is uncontroversial, but Carl dislikes the 3 lcd_filter API
+the new API is uncontroversial, but Carl dislikes the 3 `lcd_filter` API
entries---it seems we should be able to address the use cases that
have come up without any new API here.]
@@ -315,7 +315,7 @@ etc.). There are basically three ideas:
[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
+`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.
@@ -324,14 +324,14 @@ 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)
+ 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,
+ `cairo_pattern_set_image_data` (`cairo_pattern_t` *pattern,
const char *mimetype,
unsigned char *data,
unsigned int length);
@@ -384,7 +384,7 @@ array of source patterns stored by the PDF backend with a new hash
table keyed off the two counters implemented by Chris.
Carl planned to provide the final piece which is a copy-on-write
-implementation for _cairo_surface_snapshot, (so that when the
+implementation for `_cairo_surface_snapshot`, (so that when the
meta-surface makes duplicate snapshots of an identical surface the PDF
backend will see identical keys). Without the copy-on-write
implementation, the current snapshot code is currently making explicit
@@ -432,7 +432,7 @@ Fixing test-suite failures
Chris and Carl had only a very little time to look at this issue. Carl
is getting 8 failures on the image backend, (which should really
always have 0 failures). Five of these have apparently never passed
-and are related to the LCD_FILTER API, which Carl had already wanted
+and are related to the `LCD_FILTER` API, which Carl had already wanted
to just remove. Behdad agreed grudgingly. The remaining 3 failures
look simply like rasterization differences which Carl didn't track
down yet.
@@ -495,7 +495,7 @@ with Javascript that operate on the gcc data structures. We have
various things we've been wanting to do with static analysis in cairo,
(verifying that integers and fixed-point values don't get confounded,
that user-space and device-space don't get confounded, that
-cairo_status_internal_t values don't leak out, etc.).
+`cairo_status_internal_t` values don't leak out, etc.).
So it will be worth looking into these tools, (as well as sparse), to
see how to implement some of those.
@@ -513,7 +513,7 @@ Adrian and Travis spent a lot of time poring over the mesh gradient
specification in the PDF reference. The big challenge is coming up
with "cairo like" API to capture the tremendous amount of data
necessary to specify a mesh gradient. With Carl's help, a sketch of
-such an API did form, (with a series of cairo_mesh_pattern_curve_to
+such an API did form, (with a series of `cairo_mesh_pattern_curve_to`
calls to incrementally construct the mesh similar to the way a path is
constructed).
@@ -528,7 +528,7 @@ We didn't come up with any better name for these bugs, but they are
all detailed in Carl's blog post here, (and google knows that this is
what "chain of bugs" means):
-http://www.cworth.org/cairo/a_chain_of_bugs/
+<http://www.cworth.org/cairo/a_chain_of_bugs/>
Of the three bugs mentioned there, bug #1 does not appear in current
Mozilla builds, but similar issues are sure to appear again,
@@ -541,8 +541,8 @@ to expand), and Jeff agreed that it should be possible to convince
poppler to just use SOURCE for simple knockout groups, (which is what
cairo really wants). We opened this bug report to remember that issue:
-Simple knockout groups should just be rendered with CAIRO_OPERATOR_SOURCE
-https://bugs.freedesktop.org/show_bug.cgi?id=17346
+Simple knockout groups should just be rendered with `CAIRO_OPERATOR_SOURCE`
+<https://bugs.freedesktop.org/show_bug.cgi?id=17346>
We didn't get a chance to look closer at bug #3, so that will have to
wait for another day.
More information about the cairo-commit
mailing list