Windows Printing

Windows Printing

[Lennart Borgman]

It is now much easier to find documentation in Info about using Emacs on 
MS Windows (w32). That is very nice and I hope that will attract w32 
users. However when looking at this I saw a problem with the information 
in "(emacs) Windows Printing".

Eli and I (with a lot of others involved) had a very long discussion 
about this on the help-gnu-emacs mailing list:

   http://lists.gnu.org/archive/html/help-gnu-emacs/2006-01/msg00242.html

I think the tests I did clearly showed that everything does not work as 
the node above says. My conclusion was that the state of the printer is 
not reset when accessed in the way Emacs does it on w32. Getting the 
printer port is done in a standard way (I mean according to MS 
documentation) but sending the data is not supposed to be done as Emacs 
does it (if I understand this correctly, see the thread).

As it stands now I expect a lot of people to get into trouble when 
trying to print. There are two reliable ways to print on w32 that I am 
aware of (other ways has failed to me on most networked printers I have 
tried):

    - Use Ghostscript/GSview
    - Use something like htmlize.el + the web browser. (There is an 
alternative to htmlize.el but I have not tested that.)


What should we do about this node?

Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 00:20:08 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> 
> Eli and I (with a lot of others involved) had a very long discussion 
> about this on the help-gnu-emacs mailing list:
> 
>    http://lists.gnu.org/archive/html/help-gnu-emacs/2006-01/msg00242.html
> 
> I think the tests I did clearly showed that everything does not work as 
> the node above says.

That's really not an accurate summary of what was written in that
discussion.  A more accurate summary, IMHO, would be that _sometimes_,
in rare situations with strangely configured network printers, neither
the default printer port detection that is part of the Emacs startup
on Windows, nor any of the tips and tricks in the manual, succeed in
getting Emacs to print to that printer.  (Other printers on the same
system did work, IIRC.)

> My conclusion was that the state of the printer is 
> not reset when accessed in the way Emacs does it on w32. Getting the 
> printer port is done in a standard way (I mean according to MS 
> documentation) but sending the data is not supposed to be done as Emacs 
> does it (if I understand this correctly, see the thread).

Sorry, I disagree with this conclusion.  The MS docs do not say
explicitly that ``sending data is not supposed to be done as Emacs
does it'', and the simple fact is that the way we do it in Emacs works
on the vast majority of Windows systems.

> As it stands now I expect a lot of people to get into trouble when 
> trying to print.

Actually, I expect that only a very small fraction of people will ever
get into the same trouble as you did.

> There are two reliable ways to print on w32 that I am 
> aware of (other ways has failed to me on most networked printers I have 
> tried):
> 
>     - Use Ghostscript/GSview
>     - Use something like htmlize.el + the web browser. (There is an 
> alternative to htmlize.el but I have not tested that.)

The use of Ghostscript is covered by the manual, in the node you
mentioned.  As for htmlize.el, I refuse to recommend Emacs users to
use Explorer or Notepad to print on Windows.  Sorry.

> What should we do about this node?

If you or someone else can debug the problem you've been having and
find out how to work around it, I'll be happy to augment the manual.
Otherwise, I don't see what we can or should do.

Re: Windows Printing

[Jason Rumney]

Eli Zaretskii wrote:
> That's really not an accurate summary of what was written in that
> discussion.  A more accurate summary, IMHO, would be that _sometimes_,
> in rare situations with strangely configured network printers, neither
> the default printer port detection that is part of the Emacs startup
> on Windows, nor any of the tips and tricks in the manual, succeed in
> getting Emacs to print to that printer.  (Other printers on the same
> system did work, IIRC.)
>   
Without having read the entire thread, I suspect that the problem is 
that some cheap printers these days do not support printing plain text. 
We could perhaps mention that in the manual.

Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 11:59:47 +0100
> From: Jason Rumney <jasonr@gnu.org>
> CC: Lennart Borgman <lennart.borgman.073@student.lu.se>, 
>  emacs-devel@gnu.org
> 
> Without having read the entire thread, I suspect that the problem is 
> that some cheap printers these days do not support printing plain text. 

I did read the entire thread at the time, and I don't think the lack
of support for plain text was the reason.  The reason was, IIRC, that
the Emacs code that detects the default printer and sets printer-name
somehow failed to produce the right value.

Lennart, is that true, or did my memory fail me (again)?

> We could perhaps mention that in the manual.

What would we suggest as work-arounds for such situations?

Re: Windows Printing

[Jason Rumney]

[-- Attachment #1.1: Type: text/plain, Size: 414 bytes --]

Eli Zaretskii wrote:
>> Without having read the entire thread, I suspect that the problem is 
>> that some cheap printers these days do not support printing plain text. 
>>     
>> We could perhaps mention that in the manual.
>>     
>
> What would we suggest as work-arounds for such situations?
>   
I think the documentation we already have for setting up Ghostscript for 
ps-print still works in these cases.


[-- Attachment #1.2: Type: text/html, Size: 849 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 13:08:01 +0100
> From: Jason Rumney <jasonr@gnu.org>
> CC:  lennart.borgman.073@student.lu.se,  emacs-devel@gnu.org
> 
> >> Without having read the entire thread, I suspect that the problem is 
> >> that some cheap printers these days do not support printing plain text. 
> >>     
> >> We could perhaps mention that in the manual.
> >>     
> >
> > What would we suggest as work-arounds for such situations?
> >   
> I think the documentation we already have for setting up Ghostscript for 
> ps-print still works in these cases.

Okay, I will add to the manual that if the printer doesn't support
plain text, use ps-print instead.  Thanks.

Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 13:08:01 +0100
> From: Jason Rumney <jasonr@gnu.org>
> CC:  lennart.borgman.073@student.lu.se,  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >> Without having read the entire thread, I suspect that the problem is 
> >> that some cheap printers these days do not support printing plain text. 
> >>     
> >> We could perhaps mention that in the manual.
> >>     
> >
> > What would we suggest as work-arounds for such situations?
> >   
> I think the documentation we already have for setting up Ghostscript for 
> ps-print still works in these cases.

Okay, I added advice to this effect.  Thanks.

Re: Windows Printing

[Lennart Borgman]

Eli Zaretskii wrote:
> I did read the entire thread at the time, and I don't think the lack
> of support for plain text was the reason.  The reason was, IIRC, that
> the Emacs code that detects the default printer and sets printer-name
> somehow failed to produce the right value.
>
> Lennart, is that true, or did my memory fail me (again)?
>   
A little bit I am afraid, but I think my memory is a bit fading too. 
There were two problems I think. The one you mention above and the 
problem that the printer is not reset when accessed the way Emacs does 
it. However we did not agree on the second point.

I do not think there is time to change the second failure now, but it 
would be good if we could come to some consensus here. Please try to 
convince me (with some relevant links for example)!

Re: Windows Printing

[Jason Rumney]

Lennart Borgman wrote:
> A little bit I am afraid, but I think my memory is a bit fading too. 
> There were two problems I think. The one you mention above and the 
> problem that the printer is not reset when accessed the way Emacs does 
> it. However we did not agree on the second point.
What do you mean when you say "the printer is not reset when accessed 
the way Emacs does it"? Do you mean that the print job that Emacs sends 
prints OK, but then the printer becomes unusable after that?

Re: Windows Printing

[Lennart Borgman]

Jason Rumney wrote:
> What do you mean when you say "the printer is not reset when accessed 
> the way Emacs does it"? Do you mean that the print job that Emacs 
> sends prints OK, but then the printer becomes unusable after that?
>
No, it is the state before Emacs printing I refer to. I found that 
different (professional) printers were in different states before 
printing. Some accepted plain text, some accepted postscript.

Re: Windows Printing

[Jason Rumney]

Lennart Borgman wrote:
> Jason Rumney wrote:
>> What do you mean when you say "the printer is not reset when accessed 
>> the way Emacs does it"? Do you mean that the print job that Emacs 
>> sends prints OK, but then the printer becomes unusable after that?
>>
> No, it is the state before Emacs printing I refer to. I found that 
> different (professional) printers were in different states before 
> printing. Some accepted plain text, some accepted postscript.
It seems that Windows has problems if you send a reset command before a 
print job. So I don't think resetting the printer before each job is the 
answer:

http://support.microsoft.com/?kbid=123107

Re: Windows Printing

[Lennart Borgman]

Jason Rumney wrote:
> Lennart Borgman wrote:
>> Jason Rumney wrote:
>>> What do you mean when you say "the printer is not reset when 
>>> accessed the way Emacs does it"? Do you mean that the print job that 
>>> Emacs sends prints OK, but then the printer becomes unusable after 
>>> that?
>>>
>> No, it is the state before Emacs printing I refer to. I found that 
>> different (professional) printers were in different states before 
>> printing. Some accepted plain text, some accepted postscript.
> It seems that Windows has problems if you send a reset command before 
> a print job. So I don't think resetting the printer before each job is 
> the answer:
>
> http://support.microsoft.com/?kbid=123107
>
Thanks, I had not seen that page. However in my test cases all printers 
where networked shared printers. If I do not misremember I tried to use 
"copy" too as suggested on the page above.

Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 16:04:26 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > It seems that Windows has problems if you send a reset command before 
> > a print job. So I don't think resetting the printer before each job is 
> > the answer:
> >
> > http://support.microsoft.com/?kbid=123107
> >
> Thanks, I had not seen that page. However in my test cases all printers 
> where networked shared printers. If I do not misremember I tried to use 
> "copy" too as suggested on the page above.

Did you try to use lpr.exe bundled with Windows?  Did it work?

Re: Windows Printing

[Lennart Borgman]

Eli Zaretskii wrote:
> Did you try to use lpr.exe bundled with Windows?  Did it work?
>   
I do not remember right now. I will do as soon as I get a chance.

Re: Windows Printing

[Benjamin Riefenstahl]

Hi Lennart,


Lennart Borgman writes:
> I found that different (professional) printers were in different
> states before printing. Some accepted plain text, some accepted
> postscript.

Some printers support several printing languages or modes (like plain
text, Postscript and PCL).  There are printers that stay in the mode
that was used for the last print job until a timeout occurs, because
they don't actually recognise the end of the job.

The way that the high-level printer drivers that come with the OS
handle the situation is to send a prefix containing escape commands
before the actual print job.  The escape commands are crafted such
that they are ignored in Postscript mode but switch the printer to
Postscript in all other modes.

It is easy enough to add such a prefix to print jobs when printing
from Emacs.  A bit of browsing in Custom suggests setting the variable
ps-user-defined-prologue.  The problem seems to me to find out what
precisely should be in that prefix.

Often you can use some print-to-file option in the OS-supplied printer
driver to generate a dummy file.  You can than transcribe the correct
prefix bytes from that file.  When this doesn't work you really need
to look at the printer documentation, assuming you have that or can
find it on the 'Net.


benny

Re: Windows Printing

[Eli Zaretskii]

> Cc: Jason Rumney <jasonr@gnu.org>, Eli Zaretskii <eliz@gnu.org>,
>    emacs-devel@gnu.org
> From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
> Date: Fri, 19 May 2006 17:36:57 +0200
> 
> It is easy enough to add such a prefix to print jobs when printing
> from Emacs.  A bit of browsing in Custom suggests setting the variable
> ps-user-defined-prologue.  The problem seems to me to find out what
> precisely should be in that prefix.

This will only work with ps-print.  IIRC, Lennart's problem was with
printing via lpr-region and friends as well.

Re: Windows Printing

[Lennart Borgman]

Jason Rumney wrote:
> Without having read the entire thread, I suspect that the problem is 
> that some cheap printers these days do not support printing plain 
> text. We could perhaps mention that in the manual.
That is a problem too. But that was not the problem that I was writing 
about. That was all trouble with proffesional printers.

Re: Windows Printing

[Lennart Borgman]

Eli Zaretskii wrote:
>> Eli and I (with a lot of others involved) had a very long discussion 
>> about this on the help-gnu-emacs mailing list:
>>
>>    http://lists.gnu.org/archive/html/help-gnu-emacs/2006-01/msg00242.html
>>
>> I think the tests I did clearly showed that everything does not work as 
>> the node above says.
>>     
>
> That's really not an accurate summary of what was written in that
> discussion.  A more accurate summary, IMHO, would be that _sometimes_,
> in rare situations with strangely configured network printers, neither
> the default printer port detection that is part of the Emacs startup
> on Windows, nor any of the tips and tricks in the manual, succeed in
> getting Emacs to print to that printer.  (Other printers on the same
> system did work, IIRC.)
>   
Sorry, I did not want to exaggarate. But are you really sure that what 
you write here is correct? It is true that I detected one printer on the 
network that worked the way that Windows Printing in Info describes. The 
others did not.

However that is not my point. I just want to stress that the information 
in Info should be augmented. Otherwise we might waste some peoples time.

>   
>> My conclusion was that the state of the printer is 
>> not reset when accessed in the way Emacs does it on w32. Getting the 
>> printer port is done in a standard way (I mean according to MS 
>> documentation) but sending the data is not supposed to be done as Emacs 
>> does it (if I understand this correctly, see the thread).
>>     
>
> Sorry, I disagree with this conclusion.  The MS docs do not say
> explicitly that ``sending data is not supposed to be done as Emacs
> does it'', and the simple fact is that the way we do it in Emacs works
> on the vast majority of Windows systems.
>   
I am very sure about the conclusion that the printer is not reset when 
accessed from Emacs. What exactly do you disagree upon?

You might be right that this works for the majority of Windows system - 
I am not sure. But as above how can you be sure? Perhaps it is a bit 
like "all people I know vote for that"? Maybe some people gives up on 
Emacs because they find the information inaccurate? (I know some do, 
because I once did.)

We might be reading the MS documentation differently. But I tried to 
point to some parts of the manual (in the thread on the mailing list) 
that made me come to the (tentary) conclusion that printing on MS 
Windows should be done in a different way than Emacs currently does it. 
The supported way (as I read the MS docs) is through the use the GDI 
interface (which I know very little about in practice). Grabbing the 
name of the printer port is a different issue.

> The use of Ghostscript is covered by the manual, in the node you
> mentioned.  As for htmlize.el, I refuse to recommend Emacs users to
> use Explorer or Notepad to print on Windows.  Sorry.
>   
A little bit unfair. I do not recommend Notepad or Explorer. I use 
htmlize.el + Firefox ;-)

Then perhaps a link to http://EmacsWiki.org/ could be in the Info node? 
And perhaps it could be pointed out that the only recommended way that 
works for everyone on MS Windows is through the use of Ghostscript+GSview?

>   
>> What should we do about this node?
>>     
>
> If you or someone else can debug the problem you've been having and
> find out how to work around it, I'll be happy to augment the manual.
> Otherwise, I don't see what we can or should do.
>   
Both you and I did a lot of work around this. I finally said that I can 
not see any way to get further. In the situation where I found the 
problems I simply can not in a general way do more.

What can be done is sending reset sequencies to the printers, but those 
are printer specific and I would really not recommend that. Maybe it 
would help some people to mention this possibility in the manual, but it 
would in my opinion look a bit ridiculous nowadays and therefore it 
would not be in favour of Emacs or GNU.

Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 15:10:21 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  emacs-devel@gnu.org
> 
> However that is not my point. I just want to stress that the information 
> in Info should be augmented. Otherwise we might waste some peoples time.

When we know what to say for them to be able to fix Emacs printing, we
will.


> >> My conclusion was that the state of the printer is 
> >> not reset when accessed in the way Emacs does it on w32. Getting the 
> >> printer port is done in a standard way (I mean according to MS 
> >> documentation) but sending the data is not supposed to be done as Emacs 
> >> does it (if I understand this correctly, see the thread).
> >>     
> >
> > Sorry, I disagree with this conclusion.  The MS docs do not say
> > explicitly that ``sending data is not supposed to be done as Emacs
> > does it'', and the simple fact is that the way we do it in Emacs works
> > on the vast majority of Windows systems.
> >   
> I am very sure about the conclusion that the printer is not reset when 
> accessed from Emacs. What exactly do you disagree upon?

That ``sending data is not supposed to be done as Emacs does it'' on
MS-Windows.

> You might be right that this works for the majority of Windows system - 
> I am not sure. But as above how can you be sure?

Because your reports were the first time I've heard about such strange
problems.  If lots of people have them, why aren't they speaking up?

> We might be reading the MS documentation differently. But I tried to 
> point to some parts of the manual (in the thread on the mailing list) 
> that made me come to the (tentary) conclusion that printing on MS 
> Windows should be done in a different way than Emacs currently does it. 
> The supported way (as I read the MS docs) is through the use the GDI 
> interface (which I know very little about in practice).

If someone contributes code to do that, I don't think it will be
rejected.  Assuming that it blends well into the overall Emacs
printing interface (which in practice probably means we should wrap
that code in an external lpr emulator program).

> > The use of Ghostscript is covered by the manual, in the node you
> > mentioned.  As for htmlize.el, I refuse to recommend Emacs users to
> > use Explorer or Notepad to print on Windows.  Sorry.
> >   
> A little bit unfair. I do not recommend Notepad or Explorer. I use 
> htmlize.el + Firefox ;-)

Most Windows users don't have Firefox.

> Then perhaps a link to http://EmacsWiki.org/ could be in the Info node? 

That's something for the FAQ, not the manual.

Re: Windows Printing

[Lennart Borgman]

Eli Zaretskii wrote:
>> I am very sure about the conclusion that the printer is not reset when 
>> accessed from Emacs. What exactly do you disagree upon?
>>     
>
> That ``sending data is not supposed to be done as Emacs does it'' on
> MS-Windows.
>   
Why do you think it is in accordance with the MS documentation to do so? 
Do you have a pointer to some place in the documentation?

> Because your reports were the first time I've heard about such strange
> problems.  If lots of people have them, why aren't they speaking up?
>   
I did recieve some feedback from people who did not succeed before. But 
not a massive amount.

>> We might be reading the MS documentation differently. But I tried to 
>> point to some parts of the manual (in the thread on the mailing list) 
>> that made me come to the (tentary) conclusion that printing on MS 
>> Windows should be done in a different way than Emacs currently does it. 
>> The supported way (as I read the MS docs) is through the use the GDI 
>> interface (which I know very little about in practice).
>>     
>
> If someone contributes code to do that, I don't think it will be
> rejected.  Assuming that it blends well into the overall Emacs
> printing interface (which in practice probably means we should wrap
> that code in an external lpr emulator program).
>   
I took a look once but did not have time to go further. I do not know 
Emacs C code and I do not know GDI. 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. I wonder however if that is easy to do with 
Emacs. Does Emacs render the whole buffer with GDI or just the part that 
is visible at the moment?

> Most Windows users don't have Firefox.
>   
That is too bad, but maybe Emacs users have it? ;-)

>   
>> Then perhaps a link to http://EmacsWiki.org/ could be in the Info node? 
>>     
>
> That's something for the FAQ, not the manual.
Could you please explain why?

Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 20:32:31 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >> I am very sure about the conclusion that the printer is not reset when 
> >> accessed from Emacs. What exactly do you disagree upon?
> >>     
> >
> > That ``sending data is not supposed to be done as Emacs does it'' on
> > MS-Windows.
> >   
> Why do you think it is in accordance with the MS documentation to do so? 

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.

> > If someone contributes code to do that, I don't think it will be
> > rejected.  Assuming that it blends well into the overall Emacs
> > printing interface (which in practice probably means we should wrap
> > that code in an external lpr emulator program).
> >   
> I took a look once but did not have time to go further.

Same here.

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

> Does Emacs render the whole buffer with GDI or just the part that 
> is visible at the moment?

The latter, of course.  But that's for display; printing is different,
obviously.  And like I said, this code should probably live outside
Emacs in a lpr work-alike that we distribute.

> >> Then perhaps a link to http://EmacsWiki.org/ could be in the Info node? 
> >>     
> > That's something for the FAQ, not the manual.
> Could you please explain why?

Because it's a minor point.

Re: Windows Printing

[Lennart Borgman]

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.

I just want to point this out even though I guess you know. Or maybe you 
want to correct me?

>> 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? Maybe they 
could produce GDI level style calls instead (meta level of course)?

>   
>> 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 
or? I have came to the conclusion that it probably does so because of 
the multiplatform nature of Emacs. It could of course have been 
implemented differently on w32 (another abstraction level), but the 
scrolling I see on the screen does not look like something like that 
have been done. (That would be a big job I guess.)

> But that's for display; printing is different,
> obviously.  And like I said, this code should probably live outside
> Emacs in a lpr work-alike that we distribute.
>   
Yes, maybe with something like I suggest above?

>   
>>>> Then perhaps a link to http://EmacsWiki.org/ could be in the Info node? 
>>>>     
>>>>         
>>> That's something for the FAQ, not the manual.
>>>       
>> Could you please explain why?
>>     
>
> Because it's a minor point.
Ok. I do not agree but that is not necessary ;-)

The main thing in my opinion is that we should point to at least one 
supported way to print on w32 in a standard way in the Windows Printing 
node. That would be Ghostscript+GSView now then.

Re: Windows Printing

[Eli Zaretskii]

> Date: Fri, 19 May 2006 22:17:12 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  emacs-devel@gnu.org
> 
> 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.

Re: Windows Printing

[Lennart Borgman]

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.
>   
I admit I am simplyfying things. I should have thought before writing. 
The printer drivers goes in on another level.

However that has not very much to do with the main argument. There are 
some support in MS Windows for the way Emacs prints, but it is not a 
full support for all printers and all kind of printing as far as I 
understands it. You have to use GDI for that. Or do you think 
differently? (Actually I do not believe you do, but I want it to be 
clear in the archives if someone wants to work on this.)

> 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.
>   
Yes I know. I just thought that the logic for taking care of pages etc 
is there.

> 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.
>   
Thanks. Would it be hard to let the display code see the whole buffer? I 
mean for printing.

Re: Windows Printing

[Eli Zaretskii]

> Date: Sat, 20 May 2006 00:59:56 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  emacs-devel@gnu.org
> 
> However that has not very much to do with the main argument. There are 
> some support in MS Windows for the way Emacs prints, but it is not a 
> full support for all printers and all kind of printing as far as I 
> understands it. You have to use GDI for that. Or do you think 
> differently?

Yes, I think differently.  Apart of the problem mentioned by Jason,
I'm not aware of any others that prevent Emacs from printing like it
currently does.  And until we have the GDI code, that's the best we
can do.

But let's not reiterate that lengthy argument from gnu-emacs-help.

> Thanks. Would it be hard to let the display code see the whole buffer? I 
> mean for printing.

It's not hard, but it should be a subtly different code, since the
media is different.