Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 22:17:12 +0200
> From: Lennart Borgman <address@hidden>
> CC:  address@hidden
> 
> Eli Zaretskii wrote:
> > That's not what I said.  I said that I didn't see anything in the docs
> > that specifically _precludes_ us from doing what Emacs does.
> >   
> No, the printer drivers of course have to do something like that. But 
> they are printer specific. If you want to print to any printer on MS 
> Windows without having to care about what type of printer it is then you 
> must use the GDI interface instead as far as I understands it. On this 
> higher level the printer obscurities are hidden.

Sorry, you are repeating some of the nonsense written in the original
thread by someone who confessed that he knew almost nothing about how
printing works on Windows.  AFAICS, there's nothing in the Microsoft
documentation that backs up what he wrote.  Plain text output to a
printer has nothing to do with raw byte streams sent by the printer
drivers.

> >> That said my impression is that to print on w32 using GDI you should
> >> do the same thing as when you use GDI to output to the screen.
> >>     
> >
> > Yes, in principle.  But then you have the mess with choosing the right
> > fonts, including for non-ASCII characters, the mess with figuring out
> > the paper layout, etc. etc.
> >   
> Has not that kind of work been done in the ps-*.el libraries?

ps-print solves this in a different way: it talks PostScript to a
special printer driver, and that driver then takes care of converting
to GDI.  Font selection is also different, take a look at ps-mule.el
and ps-bdf.el.

> >> Does Emacs render the whole buffer with GDI or just the part that 
> >> is visible at the moment?
> >
> > The latter, of course.  
> Why of course? Is it because it would be to slow to do it another way 

Yes.  In fact, the Windows-specific display code doesn't even see the
whole buffer, only its part represented in the glyph matrices created
by the higher-level platform-independent redisplay engine.