Re: Printing from WindowXP version of emacs

[Lennart Borgman <lennart.borgman.073@student.lu.se>]

LENNART BORGMAN wrote:

>>>That sure does not look right.
>>>      
>>>
>>What doesn't look right, exactly?  I took the above as a template, not
>>as a literal string that is the printer's name.  If it's a literal
>>string, then it is indeed strange, but default-printer-name simply
>>calls GetProfileString and GetPrinter APIs, so whatever those return,
>>it's the system's notion of the printer.  Unless there's a bug in
>>default-printer-name, in which case please step through it and tell
>>what goes wrong there.
>>    
>>
>
>I have felt a bit nervous over the weekend. Did I really test this with -Q? Or is it something long forgotten I have in my initialization files.
>
>I tried again with -Q. And yes, it is literally the share name I told ("1234567890").
>  
>
I also tested to print after

    (setq printer-name (default-printer-name))

The result is somewhat perplexing perhaps, but is consistent with my 
suspiciouns. I tried two physical printers. I tested two queues on the 
first and one queue on the second.

** With "Print Buffer" I got no output from the first printer on any of 
the two printer queues I tested. On the second printer I got a correctly 
printed buffer.

** With "Postscript Print Buffer" the result was the opposite. On the 
first printer the result looks like the expeced emacs postscript print 
of the buffer for both queue. On the second printer I just got the 
postscript code printed. (And this was the color printer .... - it 
surely supports postscript. The one where I can get postscript printed 
this way is only black and white.)

To me this suggest that the way Emacs get the default printer name with 
(default-printer-name) is correct enough in at least my circumstances. 
However the name "1234567890" is not the name that the queue is normally 
known by.

The result also seems to confirm that the printing modell used by Emacs 
on w32 is not correct. The GDI model for printing is the one that 
according to MS should be used on w32 in the general case. Emacs does 
not use that model now.

So my suggested workaround using htmlize-view.el still seems to be a 
good one on w32.