From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Printing Date: Wed, 01 Apr 2009 19:55:06 +0100 Message-ID: <49D3B88A.4000809@harpegolden.net> References: jwveiwcbg87.fsf-monnier+emacs@gnu.org <49D3A2BA.5070908@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1238612375 1795 80.91.229.12 (1 Apr 2009 18:59:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Apr 2009 18:59:35 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 01 21:00:53 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 1Lp5cJ-00034r-60 for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2009 20:56:51 +0200 Original-Received: from localhost ([127.0.0.1]:50113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lp5av-0001ww-IO for ged-emacs-devel@m.gmane.org; Wed, 01 Apr 2009 14:55:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lp5ao-0001tI-1H for emacs-devel@gnu.org; Wed, 01 Apr 2009 14:55:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lp5aj-0001mr-0c for emacs-devel@gnu.org; Wed, 01 Apr 2009 14:55:17 -0400 Original-Received: from [199.232.76.173] (port=40300 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lp5ai-0001ma-Sm for emacs-devel@gnu.org; Wed, 01 Apr 2009 14:55:12 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:39870) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lp5ai-0001Pb-7I for emacs-devel@gnu.org; Wed, 01 Apr 2009 14:55:12 -0400 Original-Received: from [87.198.54.195] (87-198-54-195.ptr.magnet.ie [87.198.54.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id 62782804E; Wed, 1 Apr 2009 19:55:09 +0100 (IST) User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) In-Reply-To: <49D3A2BA.5070908@gmx.de> X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:109971 Archived-At: > If that were so then only postscript experts would be able to teach > their application to print something. > Application developers use toolkits, toolkit developers target the printing system. /Except/ on windows, that printing subsystem tends to involve postscript: A toolkit, like gtk+ with cairo, draws vectors to a postscript document [1] instead of rasterising (or sending trapezoids (xrandr) or general polys (opengl) to the display driver in the modern era) to the screen when it wants to print, then sends that postscript document to the printing daemon which does whatever is necessary to print it (for cheap printers, maybe rasterising it fully to device-specific bitmap data with ghostscript, for postscript printers, maybe munging it a bit to the postscript level the printer wants and passing it on). i.e. a hypothetical "pure gtk+ stack" emacs at the application level might well use gtk+ and cairo for both screen display and printing and abstract over the individual platform and indeed screen vs. print differences, but cairo is still probably just going to be drawing to postscript underneath for printing purposes on free or even nonfree but unixy platforms. Since emacs is currently a "toolkit unto itself" for the most part, as Stefan has already pointed out, it kind of makes sense for it to generate its own postscript. Though maybe just saving out and "enscript"ing text files might currently work about as well... On windows, the toolkit uses win32 drawing commands on a printer device context [2] instead of postscript drawing on a postscript document. Typically they might internally rasterise to a high-res DIB (.bmp) then printed with basically just one such win32 drawing command consisting of "draw this enormous .bmp please". So, if you squint *a lot*, .bmp in the windows printing world is a *little* like .ps in the nonwindows printing world. Maybe windows people might be conceptualising .ps as device-specific thing that things are printed _to_ (and it is that _too_ I guess), but it is /also/ a quasistandard intermediate format for printing in the relevant OS apis on nonwindows. Mind you, PDF would work just as well or better than postscript for that purpose, but the current de-facto standard is for OSes to expose an interface that accepts postscript documents for printing. Windows is the only vaguely relevant one that _doesn't_, pretty much, and it's only a ghostscript installation away anyway, it provides mswinpr2 to rasterise postscript to .bmps sent to native windows printers (which may then of course inefficiently convert them back to postscript to send to native postscript printers, but anyway...) [1] http://cairographics.org/manual/cairo-ps-surface.html [2] http://cairographics.org/manual/cairo-win32-surface.html