On Mon, 2007-01-22 at 18:10 -0500, Kanwar Ranbir Sandhu wrote:
On Tue, 2007-01-23 at 07:23 +0900, John Summerfield wrote:
I have a raw print queue configured in CentOS 4.4 for a printer connected to a Windows PC. The printer doesn't have a Linux driver of any sort, so this was the only way to print to it.
Umm. That means that the applications have to have a driver for the printer.
Maybe I'm just dumb. But, I thought I explained that the Okidata is connected to the Windows PC, and is configured there with the Windows driver. The printer is shared, so I added it to the CentOS 4.4 server as a raw CUPS queue to let all the processing happen on the Windows box.
Printing works from console apps on the CentOS server. But, OOo documents don't print properly. I've assumed that this is because the Windows driver for the Okidata doesn't understand postscript, so it's just printing the file directly. So, that's why I was asking if my reasoning was correct or if something else was broken.
So OOo thinks it's printing to a postscript printer. This is not going to work unless the Windows peecee translates postscript to whatever the printer expects.
Yes, that's what I've been thinking. And, it looks like the Windows driver can't do postscript.
Something broke; the problem is there right behind your eyes:-)
If you don't have a Linux printer driver for that printer, you're not going to get far unless something on Windows does the translation.
Agreed.
Check IBM's Omni driver suite (which should be installed or on your install media), there may be something usable there.
I've tried all those drivers; basically everything I could find on linuxprinting.org about getting an Okidata ML 395 working. Nothing has worked.
I have to be doing something wrong on the printer itself. Changing the printer's emulation type should have let me use one of the corresponding drivers on the CUPS end.
I'll give it another kick. Then maybe some drop kicks. Then a "whoops....don't know how it went down the stairs...strange!"
---- sounds to me like everything is working as expected. Oo is sending postcript code and the 'raw' printer is simply forwarding the code to the Windows system which is dutifully printing the raw postscript code. The thing that is missing is a postscript interpreter - hence the raw designation is a problem when printing from any GUI type application.
Probably the best thing to do is to leave the 'raw' printer alone and set up another named print queue for printing to the same Windows printer but set that up as an Epson FX-86 (just about every dot matrix printer emulates the Epson FX-86). Use that printer when printing from a GUI application such as Oo and the 'raw' printer when dumping raw text from console based applications and you should be fine.
Craig