Re: Printing from WindowXP version of emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
> Date: Tue, 20 Dec 2005 01:11:29 +0000 (UTC)
> Bcc: ilya@gnu.org
> Originator: ilya@powdermilk.math.berkeley.edu
> 
> > But if it's a Windows-style so called ``printer share
> > name'', then writing `a' to it _will_ print `a' (give or take some
> > command to force the printer to eject the page after printing a single
> > character).
> 
> What is "a command" when a pipe is concerned?  Do you mean FormFeed
> character, or what?

It depends on the printer and intimate details of its interface with
the computer.  Sending a formfeed would do in (almost) all cases, but
some printers will even do that automatically after some timeout, and
in other cases the printer driver does that.  Some old printers
required that you do that from the printer's panel.

> But I still doubt very much that what you say is actually universally
> true.  Here are some questions which force my doubts:
> 
>  In what encoding is this 'a' printed?

I don't understand the question: the printer is a display device, so
it produces a glyph, not an encoding.  Are you asking in what form the
character arrives at the printer's input line?

>  Are long lines wrapped or lost? What is the page size in lines of
>  input? Should line be terminated by CRLF, CR, or LF? 

Can't say, it depends on the printer's setup, its driver software, and
any other software that sits in between the application that sent the
text and the wire.

> My understanding of printer pipes was that they are just ways to
> communicate with the printer without any "format translation" software
> in between

Then we were talking about two different things.  The ``named pipes''
which Windows users are advised to use in conjunction with Emacs
printing are not direct ways to talk to the printer via the wire, the
traffic to those ``pipes'' is intercepted by spooling software,
translated any number of times as the printer requires (e.g., if the
printer's interface is PostScript, one of those translations converts
the sent text to a PostScript program), and eventually sent over the
wire by a printer driver.

> and contemporary printers do not have "DOS compatibility"
> mode, when you can dump arbitrary ASCII text to them, and they will
> print in Courier.

That's true.  But I wasn't talking about such a mode.  On a modern
Windows system, when you write text to LPT1, the text is captured by
system software and processed as appropriate (which indeed converts it
into commands, but that's something an application is not aware of).

> Maybe Win* stuff is organized differently

It's not, AFAIK, since `lpr' and the printer drivers after it on Unix
are conceptually similar to what happens on Windows.

> but then I would like to see an exact specification - your claim
> that 'a' is printed as 'a' shows that one cannot expect to print any
> Unicode character (given that UTF-8 is not the "Win* way").

I don't have experience with Unicode printing, so I can only
speculate.  I would think that Unicode printing requires to tell the
printer to select an appropriate font, like with terminals.

> > I will assume what happens in reality, not some silly rules of game
> > that you just invented.  In reality, the printer expects the text sent
> > to it to come in some encoding.
> 
> Definitely, *IF* it accepts text.

Well, when I said ``printer'', I actually meant the ``virtual''
printer that is all the applications knows, not the physical printer
(which indeed doesn't accept plain characters nowadays).  For an
application, the name it uses as a file or a pipe is all it knows
about the printer, and that ``virtual printer'' indeed accepts plain
text.

> > If you know how to send text from an Emacs buffer to a printer at all,
> > then sending `a' _will_ print `a'.
> 
> You again discuss "sending text".  This is hardly correlates with
> "printing" as it stands today.

I hope I explained the confusion above.

> > We are not talking at this level, since normal applications never
> > communicate to printers directly, but through some device driver or
> > some other piece of software.
> 
> On Win* this piece of software is called "the operating system".  You
> open GDI context (sp?), and draw to this context.

That's one way, yes.  But you can also set up a port, such as LPT1, to
be captured and sent to the printer, and then when you write to a file
whose name is "LPT1", the OS will do the GDI thing for you.  I think,
conceptually, this is like piping to `lpr' on Unix.

> > That funny pipe you invented is normally a symbolic name whose I/O
> > is intercepted by such an interface software and converted into
> > signals that run on the wire; then the issue of uni- vs
> > bi-directional communications is relevant.
> 
> True; but you need a way to configure this interface software.  At
> least a way to switch it to Unicode input.

Ideally, the OS would do this itself, when it sees UTF-8, but I don't
know if this is how it works.