Re: Printing from WindowXP version of emacs

[Ilya Zakharevich <nospam-abuse@ilyaz.org>]

[A complimentary Cc of this posting was sent to
Eli Zaretskii 
<eliz@gnu.org>], who wrote in article <mailman.20004.1135140203.20277.help-gnu-emacs@gnu.org>:
> 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

(May be interesting if FF-between-jobs-is-required...)

> 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".

> > > >  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.  (Yet another
question is how to *force* a sequence of bytes to be recognized as
TEXT [as opposed to MetaFile or RAW_PRINTER_COMMANDS].)

> > 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,

"Plain text" is not a description of a format.  And I do not know what
is "whatever encoding"; you have either one encoding, or some other;
obviously the pipe can't recognize both.  But these question are
already asked in two chunks above...

> > > 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.

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 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.

This has nothing to do with Unicode.  Only if you print ASCII only you
can forget about encodings; but again, in many situations even ASCII
is ambiguous - if UCS* are entring the question.  [I hope the pipe
does not try to autodetect UCSle...]

Hope htis helps,
Ilya