>>>>> On Thu, 02 Apr 2009 18:39:24 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I tried making a really preliminary proof-of-concept cairo port. :-)
> It's still rough and has several glitches/limitations, but at least
> it can generate a "resolution-independent screenshot" PDF as
> attached.  Maybe I'll clean up the code this weekend and hopefully
> post a patch.

Here's the patch for the Emacs 23.0.92 pretest (not the trunk HEAD).

* No configure support.  The easiest way would be to compile it with
  the GTK+ support that is already linked with cairo libs.  Add
  -DUSE_CAIRO to CFLAGS to activate the cairo code.

* With an experimental function (x-export-frame-image FRAME TYPE), you
  can get the current FRAME screenshot as a unibyte string in TYPE
  format.  TYPE can be 'pdf, 'ps, 'png, or 'svg if the installed cairo
  supports their formats.

* Currently, texts, rectangles (filling and stroking), and trapezoids
  for reliefs are drawn using cairo by hooking the corresponding
  drawing routine calls in xterm.c.  They use X11 GC (with extension
  data) for colors and clipping rectangles, but operations on them can
  easily be ported to non-X11 (e.g., terminal-only) environments just
  like the Carbon port.

* Images could also be drawn with cairo, but I didn't do that because
  the image drawing in xterm.c depends on X-specific data structures.
  As a result, you can't see any images in the exported screenshot as
  of now.

* Stipples are ignored (both on screen and exported one).

* Exported png images seem to be incorrect in some cases.  I suspect
  it has something to do with cairo's cluttering the activated FT_Size
  mentioned in ftcrfont.c, but I'm not sure.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp