Re: Printing from WindowXP version of emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
> Date: Tue, 20 Dec 2005 22:40:55 +0000 (UTC)
> Bcc: ilya@gnu.org
> Originator: ilya@powdermilk.math.berkeley.edu
> 
> > >  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.
> 
> Given different encodings, the same sequence of bytes should produce
> different sequence of glyphs.

Yes.  If it's encoding you were asking about, then I don't know how
this works in general for non-ASCII files on Windows.  I guess it's
similar to the way Windows uses the codepage that depends on the
current language environment, but that's a guess.

In any case, I don't think encoding is the issue in this thread, which
is about how to print from Emacs.  People who say it doesn't work for
them cannot print even simple ASCII text, where encoding is not an
issue.

> > >  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.
> 
> I'm puzzled again: if you can't say, how can you claim you know how to
> print?

Because an application that prints doesn't care about these intimate
details of the printer.  It's the system software that actually
processes the printed material (see the URL I posted here earlier)
that needs to know that.

> > 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
> 
> The key question is: translated from *what format*, and you seem to
> avoid this question again and again....

Translated initially from plain text in whatever encoding we sent it,
but the intermediate formats is something I don;t really know about,
and neither should any application care.  The system processes
involved in the translation should know that.

> > 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).
> 
> My expectation is that you are wrong.  I expect that the following is
> true on "modern Win* systems" too: you can print an arbitrary stuff
> "to a file" (as opposed "to a printer"); then sending this file (with
> printer commands, or MetaFile info - I do not know) to LPT1 will
> produce not the text representation of bytes in the file, but the
> initial (graphical) print job.

Well, you are wrong, because you assume that LPT1 goes directly to the
printer, but it's not.

> > 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.
> 
> See above.  One *must* know this before one is able to print.

That figures, because I never printed Unicode.  So I'm entitled to not
knowing.