Hi All,
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.
The printer is an Okidata dot matrix printer. Users can print to it from a console application, but if they try printing to it from OOo Writer, the printer spits out reams of pages with what looks like postscript code. The very first page has a line that says "%! PS-Adobe-3.0".
Even though the print queue is configured as "raw", why are OOo Writer print jobs still sent as postscript documents? I'm don't know too much about printing, postscript, etc., so I don't know if this is normal or if something broke.
Regards,
Ranbir
Kanwar Ranbir Sandhu wrote:
Hi All,
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.
The printer is an Okidata dot matrix printer. Users can print to it from a console application, but if they try printing to it from OOo Writer, the printer spits out reams of pages with what looks like postscript code. The very first page has a line that says "%! PS-Adobe-3.0".
Even though the print queue is configured as "raw", why are OOo Writer print jobs still sent as postscript documents? I'm don't know too much about printing, postscript, etc., so I don't know if this is normal or if something broke.
Regards,
Ranbir
what type of okidata line printer and how is it connected to the network? there are some generic dot matrix drivers for linux out there that may work for you, and depending on your model some model specific linux drivers at okidata.com.
On Mon, 2007-01-22 at 11:30 -0800, Cameron Showalter wrote:
Ranbir
what type of okidata line printer and how is it connected to the network?
It's an Okidata ML395. It's connected to a Windows 2000 PC (which we want to get rid of, but can't because of the printer and one Windows app), where the printer is being shared.
I've setup the Windows printer in CUPS as a Samba printer and raw queue.
there are some generic dot matrix drivers for linux out there that may work for you, and depending on your model some model specific linux drivers at okidata.com.
I've tried the generic dot matrix drivers, and everything suggested on the linuxprinting.org website multiple times. Nothing has ever worked. Every driver I've tried produces reams of pages with garbage on them.
It's really weird since the printer itself has a few different emulation modes, and they all have equivalent drivers in CentOS 4. But, they simply don't work. When I think about that printer my blood pressure rises.
Anyway, printing is working except from OpenOffice.org. I guess it's sending a postscript document to the printer and the Windows driver doesn't understand postscript, thinks the print job is just plain text, and starts printing it. But, like I said, I don't know much about printing systems, so I'm probably wrong.
Regards,
Ranbir
Kanwar Ranbir Sandhu wrote:
Hi All,
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.
The printer is an Okidata dot matrix printer. Users can print to it from a console application, but if they try printing to it from OOo Writer, the printer spits out reams of pages with what looks like postscript code. The very first page has a line that says "%! PS-Adobe-3.0".
Even though the print queue is configured as "raw", why are OOo Writer print jobs still sent as postscript documents? I'm don't know too much about printing, postscript, etc., so I don't know if this is normal or if something broke.
Regards,
Ranbir
Why would you want to configure the print que as raw when you are printing through an application package? I understand that the console application may need the raw que as it is probably doing all the printer formatting with the application.
Simply create another printer que to the same printer using the proper printer driver for that printer and all will be well.
Mark Snyder JMK Computerized TDIS 703 S. Glover Ave. Urbana, IL 61802 (800)397-8100
On Mon, 2007-01-22 at 13:57 -0600, Mark Snyder wrote:
Why would you want to configure the print que as raw when you are printing through an application package? I understand that the console application may need the raw que as it is probably doing all the printer formatting with the application.
The problem is that the Linux drivers don't work - they never have. Even the console app doesn't work (it doesn't do any formatting or printer control). So, the only way to print anything to it is through the Windows machine. It's set up as a raw queue on the Linux side in order to let the Windows PC process the print jobs.
Simply create another printer que to the same printer using the proper printer driver for that printer and all will be well.
Oh, how I would _love_ to do that. I need to set the printer on fire. It'll be better for everyone.
Regards,
Ranbir
Kanwar Ranbir Sandhu wrote:
On Mon, 2007-01-22 at 13:57 -0600, Mark Snyder wrote:
Why would you want to configure the print que as raw when you are printing through an application package? I understand that the console application may need the raw que as it is probably doing all the printer formatting with the application.
The problem is that the Linux drivers don't work - they never have. Even the console app doesn't work (it doesn't do any formatting or printer control). So, the only way to print anything to it is through the Windows machine. It's set up as a raw queue on the Linux side in order to let the Windows PC process the print jobs.
Simply create another printer que to the same printer using the proper printer driver for that printer and all will be well.
Oh, how I would _love_ to do that. I need to set the printer on fire. It'll be better for everyone.
Regards,
Ranbir
We use the Okidata printers all the time without any problem. We use them with a small dedicated print server box connection via our TCP network. Set up the printer to use either the epson emulation or the IBM proprinter emulation, we have had no success with the Okidata emulation. For our console application we setup a raw printer que, for everything else we use the appropriate driver for the printer emulation set on the printer.
Can you do a test to the printer from the Windows box? You must get that working first then match the print driver on cups to the Windows driver. One of the Epson FX series will work the best. It would be much less troublesome to just use a dedicated print server as we do.
Good Luck Mark
On Mon, 2007-01-22 at 15:40 -0600, Mark Snyder wrote:
We use the Okidata printers all the time without any problem. We use them with a small dedicated print server box connection via our TCP network. Set up the printer to use either the epson emulation or the IBM proprinter emulation, we have had no success with the Okidata emulation. For our console application we setup a raw printer que, for everything else we use the appropriate driver for the printer emulation set on the printer.
Ok. Well, the printer is an ML 395. I guess I can try using the other emulation types again, and try out the appropriate driver.
Can you do a test to the printer from the Windows box? You must get that working first then match the print driver on cups to the Windows driver. One of the Epson FX series will work the best.
Printing from console apps on the Linux side is okay. I'll try printing the OOo document directly from the Windows PC.
It would be much less troublesome to just use a dedicated print server as we do.
Tried that too. I did the dedicated print server test because I wanted to make sure the parallel port on the server wasn't busted or maybe misconfigured in the BIOS. It wasn't though - the print server messed things up too.
I'm starting to think the printer is just broken - maybe the other emulation types just don't work.
Thanks for your help.
Regards,
Ranbir
Kanwar Ranbir Sandhu wrote:
Hi All,
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.
The printer is an Okidata dot matrix printer. Users can print to it from a console application, but if they try printing to it from OOo Writer, the printer spits out reams of pages with what looks like postscript code. The very first page has a line that says "%! PS-Adobe-3.0".
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.
Even though the print queue is configured as "raw", why are OOo Writer print jobs still sent as postscript documents? I'm don't know too much about printing, postscript, etc., so I don't know if this is normal or if something broke.
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.
Check IBM's Omni driver suite (which should be installed or on your install media), there may be something usable there.
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!"
Regards,
Ranbir
Have you tried a generic PCL5e, PostScript or dot-matrix driver and send it strait to the printer? a lot times a generic driver will work.
I would imagine you have a PCL driver on the windows machine. Also have you set up a share on the windows machine. Make sure you gone through all the basics.
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!"
Regards,
Ranbir
-- Kanwar Ranbir Sandhu Linux 2.6.19-1.2895.fc6 i686 GNU/Linux 18:00:55 up 1 day, 2:56, 2 users, load average: 0.03, 0.21, 0.19
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Brent wrote:
Have you tried a generic PCL5e, PostScript or dot-matrix driver and send it strait to the printer? a lot times a generic driver will work.
I would imagine you have a PCL driver on the windows machine. Also have you set up a share on the windows machine. Make sure you gone through all the basics.
Brent Do you know a dot-matrix printer that does PCL or postScript? (Well, deskjets, sort of, maybe).
I don't know the printer concerned, but if it's 24-pin then Epson LX-24 emulation is a possibility.
I don't know of any dotmatrix postcript printers either.I must have been out kind of tired.
What I meant to say is I just wanted to know if they tried the epson pro printer or epson LQ drivers and not use the postcript or PCL drivers that most people tend to use.
Brent wrote:
Have you tried a generic PCL5e, PostScript or dot-matrix driver and send it strait to the printer? a lot times a generic driver will work.
I would imagine you have a PCL driver on the windows machine. Also have you set up a share on the windows machine. Make sure you gone through all the basics.
Brent Do you know a dot-matrix printer that does PCL or postScript? (Well, deskjets, sort of, maybe).
I don't know the printer concerned, but if it's 24-pin then Epson LX-24 emulation is a possibility.
--
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
Please do not reply off-list _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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
-
Brent -
Cameron Showalter -
Craig White -
John Summerfield -
Kanwar Ranbir Sandhu -
Mark Snyder