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.19893.1135054520.20277.help-gnu-emacs@gnu.org>:
> >  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.

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

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

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

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.

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

There is no way to reliably distinguish UTF-8 from any other byte stream.

Hope this helps,
Ilya