From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Future of display engine [Re: Printing] Date: Wed, 08 Apr 2009 10:19:33 +0900 Message-ID: References: <5f0660120903280331y780c80b7i57a8115dc4b029eb@mail.gmail.com> <49CE3A84.9070705@swipnet.se> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1239153539 26817 80.91.229.12 (8 Apr 2009 01:18:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Apr 2009 01:18:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 08 03:20:18 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 1LrMSd-0003HT-Rl for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2009 03:20:16 +0200 Original-Received: from localhost ([127.0.0.1]:60094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrMRF-0001Al-Gm for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2009 21:18:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrMRA-0001AW-PN for emacs-devel@gnu.org; Tue, 07 Apr 2009 21:18:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrMR5-0001AK-4r for emacs-devel@gnu.org; Tue, 07 Apr 2009 21:18:43 -0400 Original-Received: from [199.232.76.173] (port=51276 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrMR4-0001AH-UN for emacs-devel@gnu.org; Tue, 07 Apr 2009 21:18:38 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:39904) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LrMR4-0005d8-BH for emacs-devel@gnu.org; Tue, 07 Apr 2009 21:18:38 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n381IVM7003492; Wed, 8 Apr 2009 10:18:31 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n381IVWR001282; Wed, 8 Apr 2009 10:18:31 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp2.aist.go.jp with ESMTP id n381IVjK026470; Wed, 8 Apr 2009 10:18:31 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LrMRx-0002hI-Rn; Wed, 08 Apr 2009 10:19:33 +0900 In-reply-to: (message from YAMAMOTO Mitsuharu on Tue, 07 Apr 2009 10:14:52 +0900) X-detected-operating-system: by monty-python.gnu.org: Solaris 9 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:110133 Archived-At: In article , YAMAMOTO Mitsuharu writes: > > That doesn't answer my question. As I now don't remember well when > > and how it is used, just by reading your comment, I don't understand > > what is the problem of using (struct glyphs_string *)->clip, and how > > using GC extention data solves it. > Not a problem, but just a matter of uniformity. Even in the current > xterm.c, colors and clipping information is managed by GC for drawings > except texts. The use of GC extension data enables us to get rid of > this special treatment for text drawings. Ah, I see your point. I was thinking the other way round. I vaguely think we can have more uniform display engine if we can have various information for displaying in a device independent way. Though, I have not investigate it in detail. --- Kenichi Handa handa@m17n.org