-[[meta title="A chain of bugs"]]
+[[!meta title="A chain of bugs"]]
+
+[[!tag cairo]]
With cairo's recent 1.6.4 release, we've hoped to reach the nirvana of
applications that display and print documents with perfect
reveals at least three independent problems that conspire to give the
bad results.
-# Bug 1: Firefox+cairo uses image fallbacks for table borders
+## Bug 1: Firefox+cairo uses image fallbacks for table borders
First, here's the simplest web page I was able to construct to show
the problem, (nothing more than a single-cell table with a border):
file" and obtained the following PDF output: [[bug.pdf]] (14,465
bytes).
-This output is still quite accurate and farly usable. But we've
+This output is still quite accurate and fairly usable. But we've
already seen problem #1. Note that the file size has increased by a
factor of 100 compared to the original HTML. The PDF does have more
content, (firefox adds a header and footer for example), but nothing
it uses a "knockout group" to do so. This is a particular PDF
construct that I'll discuss later.
-# Bug 2: Poppler+cairo expands knockout groups to full-page fallbacks
+## Bug 2: Poppler+cairo expands knockout groups to full-page fallbacks
Next, we can use the poppler library, (with evince or a pdf2ps
utility), to read the PDF file and use cairo to generate a PostScript
To explain a bit, (but ignoring many gory details), a PDF knockout
group can be a very complicated thing, so poppler has some fairly
sophisticated code to handle these. This support involves rendering
-everything in the group twice and then using cairo's DEST_OUT and ADD
+everything in the group twice and then using cairo's `DEST_OUT` and `ADD`
compositing operators to properly combine them. Well, PostScript can't
-do fancy compositing like DEST_OUT and ADD, so of course cairo falls
+do fancy compositing like `DEST_OUT` and `ADD`, so of course cairo falls
back to image-based rendering for things. The irony here is that the
only reason cairo is using a knockout group in the original PDF file
is to _prevent_ any compositing from happening, (the fallback image
cairo's PostScript backend so that we don't get this full-page fallback
explosion.
-# Bug 3: Cairo uses the wrong resolution for fallback images (in groups)
+## Bug 3: Cairo uses the wrong resolution for fallback images (in groups)
If it were only for those first two bugs, the intermediate file sizes
would have been larger than normal, but the final result would have
looked great and printed just fine. And in that case, I probably would
have never even received a bug report.
-But there's a third problme that is the most pernicious, because it
-results in the final result looking ust awful. When cairo inserts the
+But there's a third problem that is the most pernicious, because it
+results in the final result looking just awful. When cairo inserts the
full-page fallback into the final PostScript file, it is inserting it
at 300dpi, but it does that only after rendering it to an intermediate
72dpi image, which is then scaled up. That's why the final PostScript
file). However, the original HTML table is now entirely missing. So
there's definitely something wrong with my patch.
-I'll continue to chase these bugs down, and continue my quest to get
-high-quality display and print output from cairo-using
-applications. It can be a difficult goal, but it's also a lot of fun
-and very rewarding.
-
-Please feel free to jump in and help if you're interested.
+I'll continue to chase these bugs down. The interesting thing about
+this chain is that it's only as strong as its weakest link. Fixing any
+of the individual problems here will make the end-to-end behavior be
+quite acceptable.
+And I'll continue my quest to get high-quality display and print
+output from cairo-using applications. It can be a challenging goal,
+but it's also a lot of fun and very rewarding. Please feel free to
+jump in and help if you're interested.
projects / cworth.org / blobdiff