From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Printing Date: Sat, 04 Apr 2009 16:25:46 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <5f0660120903280331y780c80b7i57a8115dc4b029eb@mail.gmail.com> <49CE3A84.9070705@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1238829970 19478 80.91.229.12 (4 Apr 2009 07:26:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2009 07:26:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 04 09:27:28 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Lq0Ho-0005rV-7N for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2009 09:27:28 +0200 Original-Received: from localhost ([127.0.0.1]:35082 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lq0GQ-0000rT-A3 for ged-emacs-devel@m.gmane.org; Sat, 04 Apr 2009 03:26:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lq0GL-0000rO-O6 for emacs-devel@gnu.org; Sat, 04 Apr 2009 03:25:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lq0GG-0000qg-Nc for emacs-devel@gnu.org; Sat, 04 Apr 2009 03:25:57 -0400 Original-Received: from [199.232.76.173] (port=56172 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lq0GG-0000qd-FM for emacs-devel@gnu.org; Sat, 04 Apr 2009 03:25:52 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:56691) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lq0GE-0007xl-VN for emacs-devel@gnu.org; Sat, 04 Apr 2009 03:25:51 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id A9EF42C40; Sat, 4 Apr 2009 16:25:46 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by monty-python.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:110058 Archived-At: >>>>> On Sat, 4 Apr 2009 08:54:32 +0200, Lennart Borgman 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