[cairo] Progress on cairo-based "print to PDF" from Mozilla

[Carl Worth]

It's time for a status update on how "printing" is looking in cairo
these days. The baseline I've been using is a "print to file" of the
Minefield start page in a Mozilla trunk build tweaked to use cairo's
PDF backend instead of its PS backend. [*]

Here's what that output looks like right now with the head of cairo
development (and what will be in the 1.1.8 snapshot I'm making today).

http://cairographics.org/~cworth/images/minefield-type3.pdf

There is some good, some bad in that image. Here are a few things to
note. The "Bad" things here are all bugs that should block the release
of cairo 1.2. I'd love to have some help at knocking a couple of these
off.

First page
----------
Bad:  The first page is an image fallback, but there's no good reason
      for it to be, (and the last time I ran this test it wasn't). So
      there's been some regression in the PDF capability analysis.

      Effort to fix: Very minor (I'll do this)

Good: Given that the first page _is_ an image fallback, it's great to
      see that it's now being properly rendered at a high-quality
      resolution. This is due to the very recent effort to fix the old
      set_dpi API (and rename it to set_fallback_resolution). Previously
      the image fallbacks were stuck at 72 DPI, but this is now coming
      out at 300 DPI as the mozilla code requests.

Bad:  The text in the four corners of the first page is being rendered
      at a tiny scale. This looks like I just missed a case when I did
      the recent set_fallback_resolution work.

      Effort to fix: Minor (I'll do this)

Second page
-----------
Good: This page is coming out as all-native, vector PDF, which is
      good. We'd basically like cairo 1.2 to provide this for most
      anything that mozilla will print.

Bad:  If you zoom in a fair amount on the glyphs on this page you'll
      see that some have odd shapes, (notice 'r' and 'c' for
      example). It appears that the glyphs are being hinted at the
      wrong DPI somewhere, (but ideally there would be no hinting
      applied at all for glyphs being output to PDF).

      Effort to fix: Unknown (someone want to look into this?)

Bad:  You'll notice that the small text in the four corners of this
      page is showing up as black boxes instead of the real
      text. What's happening here is that mozilla is selecting a
      bitmap font on my system and we don't yet have complete support
      for bitmap fonts in the type3 font output. The function that
      needs to be fixed is _cairo_pdf_surface_emit_bitmap_glyph. It
      has access to an image surface within scaled_glyph and can call
      the existing emit_image function to output it. Then it's simply
      a matter of referencing the resulting resource ID and perhaps
      accounting for a flipped Y axis or perhaps some other scaling,
      (see example code of calling emit_image, referencing, and
      transforming in emit_surface_pattern though this will be less
      complicated).

      Effort to fix: Moderate (someone want to take this?)

Meanwhile, I also did a test with krh's truetype font subsetting
branch merged in, (the merged branch is available in my
mozilla-test-type branch). Here's the result from that test:

http://cairographics.org/~cworth/images/minefield-type42.pdf

This looks extremely promising. The upshot is that most of the type3
font output from the previous test is now emitted as embedded truetype
fonts instead, (the bitmapped text that still appears as boxes in the
corner remains a type3 font). The hinting problems are now gone, and
viewers such as evince and acroread now attempt to provide text
selection capabilities.

However, I did not succeed at successfully copying any text from this
document with either viewer. With acroread, the selection bars feel
twice as tall as they should be and if I try to copy, I end up with
garbage getting pasted, (in gnome-terminal anyway---and I should say I
don't think I've ever attempted copy and past from acroread before so
it's possible there are bugs here that aren't cairo's fault).

But I don't think that cairo is in the clear since evince also fails
to select text, and it does so quite spectacularly. Take a look at
this screenshot of krh trying to select something:

http://people.freedesktop.org/~krh/minefield-selection.png

I'm inclined to wait on this newer code until the selection behavior
improves a bit.

-Carl

[*] It's worth pointing out one excellent development. With the recent
effort to merge upstream as many of mozilla's cairo patches as
possible, it's now easier than ever to build mozilla against upstream
cairo. We're now only one patch away from being able to build mozilla
with --enable-system-cairo against cairo head. The one patch is the
get_clip_as_rectangles stuff that Robert has been working on. (The
patch I used for my testing is available from the query-clip branch in
my personal cairo repository. Or you could grab my mozilla-test branch
which is cairo's head with that merged in.)







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