Re: Printing

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Sat, 4 Apr 2009 08:54:32 +0200, Lennart Borgman <lennart.borgman@gmail.com> 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).

>> * 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.

> Does this work on w32?

No.  Because I hooked to the drawing routine calls in xterm.c to
minimize the changes as the first step, which is intended for doing
some experiments whether cairo is useful for printing in Emacs.

If it is proved to be useful, then the next step would be to introduce
page-device frames in contrast to the existing screen-device frames,
so as to make the cairo drawing work without window systems.  That's
why I mentioned X-specific data structures above.  As seen by the size
of the changes to xterm.c, core drawing code can be shared between
these different types of frames.

Actually, the design of the cairo patch is based on that of the
Carbon(+AppKit) port.  The work of rewriting from Xlib to cairo was
very similar to that from QuickDraw to Quartz 2D.

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