From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Benjamin Riefenstahl Newsgroups: gmane.emacs.devel Subject: Re: Emacs Installer for MS Windows Date: Thu, 26 Aug 2004 21:41:49 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <001401c478de$908a92d0$0200a8c0@sedrcw11488> <1091508072.20683.201576204@webmail.messagingengine.com> <4111491A.4090601@runestig.com> <4111D8D4.1040506@runestig.com> <1091693906.8538.201741376@webmail.messagingengine.com> <001d01c47afa$c1f5f170$0200a8c0@sedrcw11488> <003e01c48946$a8ebfad0$0200a8c0@sedrcw11488> <011201c48a06$469eb6e0$0200a8c0@sedrcw11488> <016f01c48a10$f6081090$0200a8c0@sedrcw11488> <001801c48a37$995d27f0$0200a8c0@sedrcw11488> <01c48a5a$Blat.v2.2.2$412bdd60@zahav.net.il> <412DFF1B.9010603@ig.com.br> <16686.4094.173795.914606@tron.eng.it> <004001c48b8d$f622ec70$0200a8c0@sedrcw11488> <412E20A5.3050407@ig.com.br> <000d01c48b9c$763a5570$0200a8c0@sedrcw11488> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1093549327 31264 80.91.224.253 (26 Aug 2004 19:42:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 Aug 2004 19:42:07 +0000 (UTC) Cc: Eli Zaretskii , Vinicius Jose Latorre , saint@eng.it, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 26 21:41:55 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C0Q8A-00083q-00 for ; Thu, 26 Aug 2004 21:41:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C0QCo-00038J-0b for ged-emacs-devel@m.gmane.org; Thu, 26 Aug 2004 15:46:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C0QCh-000371-9B for emacs-devel@gnu.org; Thu, 26 Aug 2004 15:46:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C0QCg-00035K-0L for emacs-devel@gnu.org; Thu, 26 Aug 2004 15:46:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C0QCf-00035E-U6 for emacs-devel@gnu.org; Thu, 26 Aug 2004 15:46:33 -0400 Original-Received: from [193.28.100.151] (helo=mail.epost.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C0Q7q-00056a-Dm; Thu, 26 Aug 2004 15:41:34 -0400 Original-Received: from seneca.benny.turtle-trading.net.epost.de (193.99.153.30) by mail.epost.de (7.1.026.1) id 412D36F800019D90; Thu, 26 Aug 2004 21:41:33 +0200 Original-To: "Lennart Borgman" In-Reply-To: <000d01c48b9c$763a5570$0200a8c0@sedrcw11488> (Lennart Borgman's message of "Thu, 26 Aug 2004 20:42:22 +0200") User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3.50 (gnu/linux) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:26535 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:26535 Hi Lennart, "Lennart Borgman" writes: > Word (or any other program that wants to print) talks to a printer > driver. This driver has specific information about the printer > choosen. Whether the translation to PostScript takes place in Word > or in the printer driver is not entirely clear to me. In the Word/Notepad/Mozilla scenario the fact that the printer uses PostScript is a private agreement between the printer driver and the printer device. The printer driver is a plugin DLL for the Windows graphics API, the so-called "GDI". Word (or Notepad or Mozilla) is just calling the GDI API to print. The GDI routes all calls from the application to the printer driver. The printer driver does the right thing, it creatES PostScript, PCL, Epson escape sequences or whatever. Than the driver gets that to the device or to an intermediate printer queue. > However the version of Acrobat that create the pdf document acts as > a printer dirver and it has the capability to create a pdf document > from any program from which you can print. A printer driver in the above scenario can do anything it wants with the application calls. Adobe's PDF-driver just decides not to connect to any hardware device, instead it asks the user for a filename. As this is all in DLLs (shared libraries) inside the printing foreground process, putting up a dialog to ask for a filename is not considered a problem. > This makes me believe there is some kind of meta-language for > description of the printout that is translated to PostScript by the > printer driver. Usually there is no intermediate format involved, just calls to the API and from there to the driver interface. You *can* just collect all those calls into a file and re-play that file later, that's the format that is called a Windows metafile (WMF or more recently EMF). But that is an exception, not the usual case. > Probably there then must be open source code for things like this in > Open Office and Mozilla. Emacs works differently at the moment. It creates a representation that it thinks is suitable for a printer and than it calls a program to put this formatted document directly into a printer queue. This by-passes the Windows printer driver. Emacs has two implementations for formatting, one using line-printer style plain text (lpr.el) and one using PostScript (ps-print.el). This mode of operation does work where either of these formats is supported and sufficient. For nicer-looking results you want to use ps-print.el, of course. Non-PostScript printers can be made to work on Windows in this manner by using Ghostscript as the program to call, as was already mentioned. Ghostscript includes a driver that uses GDI for its work (more or less the reverse of that PDF printer driver above). This mode works with any Windows printer. Of course printer-specific Ghostscript drivers should give better results. If you want OOTB printing for Emacs on Windows for any printer, you need either bundle (and automatically configure) Ghostscript, or you need to write a third printing implementation similar to ps-print.el that uses GDI calls. The first solution is larger, but much easier to implement and automatically compatible with code that builds on top of ps-print.el. Given that disk space and bandwidth is cheap these days and that Ghostscript is free, it may be the way to go. This could be part of the Windows installer. You may want to download Ghostscript as an automated step during installation and only, when it is not already installed. I.e. make a customization option in the installer to either download Ghostscript or pick an existing installation or to do neither (that option would only be available at "expert" level, I guess). benny