Re: Emacs Installer for MS Windows

[Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de>]

Hi Lennart,


"Lennart Borgman" <lennart.borgman.073@student.lu.se> 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