[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 23.0.50; ps-print-buffer-with-faces hangs on w32

From: Lennart Borgman (gmail)
Subject: Re: 23.0.50; ps-print-buffer-with-faces hangs on w32
Date: Thu, 10 Jan 2008 17:11:36 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071031 Thunderbird/ Mnenhy/

Jason Rumney wrote:
Lennart Borgman (gmail) wrote:

What exactly does this mean?

Does any Emacs variable have the value "C:\\PRN"?

The variable `printer' above.
I don't have a variable `printer', is this from an external package you have installed?

Hi Jason,

No, it is a variable in the function I mentioned in the bug report:

  Emacs hangs in direct-print-region-helper in the call to

    (write-region start end printer t 0)

  at the end of the function. Emacs is completely hanged. I have to
  kill Emacs from Windows Task Manager.

This function is in dos-w32.el.

I do have a variable `printer-name', but it's default value on Windows is the device name "PRN",

I have the same.

not "C:\\PRN"

This is what Emacs has translated "PRN" to at the end of the function above.

What is a "Windows printer"?

I forgot what these printers are called. It seems like they are called "GDI printers" or "winprinters".
Calling them winprinters suggests that there is something that makes them a win over other more functional printers.


Really the printer hardware is not the issue, often the printer will be better supported by Free Software like CUPS than by the manufacturers own Windows drivers, so calling them Windows printers is also misleading. What you really mean is that the Windows printer drivers that the manufacturer has supplied are limited to supporting only GDI based printing, as they do not expose a character device (and are connected via USB, so the COM or PAR character devices are not automatically available)


that could be used to print directly to the printer in text mode or whatever command language(s) that the printer supports natively (eg Postscript, PCL or ESC/P). This problem can often be worked around by sharing the printer from Windows, and setting the printer-name within Emacs to the network share path of the printer (eg "//localhost/printer").

Yes, that is perhaps a nice little trick. Though I had never had any reason to test it, but if you think it works then maybe this is something worth mentioning on (info "(emacs) Windows Printing")?

But it is unlikely that a printer with such limited drivers supports Postscript natively, so to use the ps-print commands, you'll need to set up a software postscript interpreter such as Ghostscript anyway.

That is correct, but it is not the problem I am reporting. I must have made some bad mistake in my initial bug report since both you and Eli misunderstood me this way.

What I was reporting was that under certain (rather common conditions) Emacs can hang if a user tries to print a file. Emacs hangs very badly and can not be interrupted. You have to kill Emacs from outside - and that of course means that the user can loose data.

(It has nothing per se with ps-print-* to do, it hangs in the same way if one uses print-buffer. I actually did M-x ps-print-buffer just to see how Emacs failed.)

So my question is what we can do about this?

I doubt that there is anything we easily can do technically about it since I notice that in a cmd.exe console

   copy /b some-non-emtpy-file.txt PRN:

hangs the console window rather badly.

I think however that we should do something since GDI printers are common on w32. What we can do is to warn the user. The best way IMO would be to add a y/n question in the function direct-print-region-helper in dos-w32.el that warns the user that Emacs might hang. (And of course an option to bypass the question.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]