Re: Printing from WindowXP version of emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
> Date: Thu, 22 Dec 2005 23:11:24 +0000 (UTC)
> Bcc: ilya@gnu.org
> Originator: ilya@powdermilk.math.berkeley.edu
> 
> > 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.
> 
> Easy to check.  Make some file with bytes in the rage 160..255, then
> do
> 
>   chcp 1252
>   copy this-file LPT1
>   chcp 1251
>   copy this-file LPT1
>   chcp 866
>   copy this-file LPT1

Yes, easy.

> > 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.
> 
> Maybe.  But what I was reacting on was your initial claim similar to
> "ALL one needs for printing under Win* is to know a name of a pipe".
> In my book, "printing ASCII" is hardly equivalent to "printing".

I didn't realize I was talking to lawyers, so forgive me if my wording
was not rigorous enough.

> > > > >  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.
> 
> ???  IIRC, now we are discussing not the printer, but the pipe...
> Anyway, consider these questions as concerning a pipe.

If you send text to the pipe (using COPY or file I/O, like Emacs
does), you don't need to be bothered by these details (with the
exception of the EOLs, which I think must be CRLF).  They are taken
care of by the machinery that takes over once the text winds up in the
pipe.

> (Yet another question is how to *force* a sequence of bytes to be
> recognized as TEXT [as opposed to MetaFile or
> RAW_PRINTER_COMMANDS].)

I think the COPY method cannot send RAW commands or EMF.  I think to
send RAW and EMF one needs to use suitable functions of the Windows
API, not simple file I/O.

> > > 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.
> 
> According to the MS links you posted, I'm right; this pipes accepts
> RAW_PRINTER_COMMANDS.  How it distinguishes it from "plain text"
> (which it supports "too", whatever it means) is not documented...

I think it distinguishes given the API calls you use to send the
stuff.

> Only if you print ASCII only you can forget about encodings

I think this is also true if you use the encoding native to the
current locale, since the printer most probably supports that by
default.