Red Hat Bugzilla – Bug 124250
prints postscript as text on dot matrix printer
Last modified: 2007-11-30 17:07:02 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 MultiZilla/1.6.4.0b Description of problem: The server is installed to a site with four dot matrix printers, including an Oki 390, and an Epson FX870. All four printers talk the same epson dialect. The printers are connected in different ways - one on lp0, one on a planet print server, one shared thorugh smb and one on a stallion terminal server (this is the only serial connection). All four printers worked correctly on the old server, which ran SCO OpenServer 5.0.5 Documents we are trying to print use some Epson escape sequences for bold, underline, cpi etc but are mainly straight text. For testing we generally use "tail /etc/hosts | lp -d<printer>", sometimes adding -c or -s. Through redhat-config-printer we always set the options to send a form feed, send an EOT, and assume unknown data is text. We unset prerender postscript and convert text to postscript, although we have tested with both of these turned on, and only one turned on. We have tried the drivers as forced for these printers (omni-compiled), and both the epson and epsonc drivers. With all of these options, the printer still gets sent postscript, or some prerendered garbage. We have tried the "raw" printer type. This does not give the option of automatic page breaks at the end of the job. We have tried text only which results in postscript being printed. Version-Release number of selected component (if applicable): cups-1.1.17-13.3.6 How reproducible: Always Steps to Reproduce: 1.Configure a dot matrix printer simmilar to one shown above 2.Print a simple text document 3. Actual Results: Postscript or unprintable/extended charactrs are printed over the next tens to hundreds of pages. Expected Results: A copy of the printed text should appear with a form feed as appropriate at the end of the page. Additional info:
If you have Epson escape sequences in your document you must send it as a raw print job -- nothing else can make any sense. Only the printer will interpret the escape codes. So the problem is that no form-feed character is appended to submitted raw jobs, is that correct? Would everything work as you expect if a form-feed character was automatically appended?
In my specific case the ability to add an automatic form feed (in case one was not already added) to a raw print queue would fix my problem. It will not fix the general problem of setting up a dot matrix printer as the appropriate model and then trying to print a straight text file (eg /etc/hosts). In this case you would still get postscript printing out.
So there are two problems you're seeing (just trying to clarify): 1. Non-raw jobs not printing properly. 2. Form-feed is not automatically appended to raw jobs Let's concentrate on 1 first. Your queue configuration should list the model (or a very close match) in the Printer Driver tab. Please make sure that's how it is set, then try printing /etc/hosts. If that prints PostScript text: 1. Attach the output of 'printconf-tui --Xexport', making sure to replace any passwords it contains with "***", and 2. Let me know which queue you printed to and which make and model the printer is. Then I can see exactly what the settings are. If we can try this with a printer whose model is explicitly listed in the Printer Driver list, all the better. Thanks.
Created attachment 100982 [details] Text only configuration
Created attachment 100983 [details] Printer configured as LQ-2080
Created attachment 100984 [details] Test file
Sorry about the delay - bad time of year for us. I have just configured a fifth dot matrix, an Epson LQ 2080. This is specifically listed in redhat-config-printer. It is an "Esc/P2" printer, which is listed as fully supported inder RH7.x in the hcl. All 4 other printers are also Esc/P2 compatible printers. I have attached configurations as both a text only printer and as an LQ-2080. Both caused garbage to print. Configuring as a raw print queue allowed up to print correctly. The printer is about 400km away from me, without a fax machine nearby. Therefore, I can't define "garbage" much further. The third attachment is the file I am printing.
(Sorry for the delay: I've been away for the last couple of weeks.) Thanks. There seems to be two problem areas: 1. Text-only printing uses postscript.ppd as the basis for the PPD file, and does not take steps to prevent texttops being used as a filter, which obvious bad effects. Also, after defining a text-only printer the test page sent is PostScript instead of the ASCII test page. 2. The Omni driver apparently doesn't work (in some way) for this device.
The main part of this (text-only printing) is redhat-config-printer's fault, so I'm changing the component.
I have built a package (system-config-printer-0.6.108-1) in Fedora Core development that I hope will address this text-only problem. This will appear in Red Hat Enterprise Linux 4. If you would like an experimental package to test on Red Hat Enterprise Linux 3 please let me know and I will try to put one together.
It would be great to have a RHEL 3 package, thanks!
Please try 0.6.47.3.20-1 from this location: ftp://people.redhat.com/twaugh/tmp/redhat-config-printer/
I tested these packages on RH9. Printing a 4 line /etc/hosts resulted in one line of garbage characters. Is it worth my while to test on RHEL or am I likely to get the same result?
They are built for Red Hat Enterprise Linux 3, so I can't really say what effect they might have on other operating systems. The printing subsystem is a set of fairly tied-together packages, so it's not unusual to get unexpected results if there is a mis-match somewhere. I would certainly appreciate feedback about how they behave on Red Hat Enterprise Linux 3!
Does anyone have positive feedback about the experimental 0.6.47.3.20-1 package, or doesn't it work for anyone but me?
I installed the experimental package on my version 3.0 es and there was no change in the output to the printer. i am using okidata microline 320 turbo printers. i have tried the omni and okibm drives and neither one prints correctly. the only way to get the printer to work is to us the raw device, but that has o problem. i can not get it to do a form-feed after printing.
Please set the queue as a 'Text only printer' (it's the option next to a raw print queue) -- this should now work.
i have changed the printer to be "Text only printer". now when i issue the following comand "lp -dlp16 file.txt" it is printing a report that looks like a text printer interface. here is a example of the first couple of lines printed %!PS-Adobe-3.0 %RBINumcpies:1 %%Pages: (atend) %%BoundingBox: 0 0 612 792 and it continues on. i have not let it finish to deteremine if it ever prints file.txt
I've found a problem that could explain that, and updated the test packages. Please try 0.6.47.3.21-1 from ftp://people.redhat.com/twaugh/tmp/redhat-config-printer/ (You may have to change the queue trivially and click 'Apply' to get it to regenerate the CUPS configuration.)
installed new package and now the printer is printing the requested jobs thru the OS ie "lp -dlp16 file.txt" using "Text Only printing". when trying to print from our application nothing is showing up. the only thing i can think of is that we are sending esc chars to control pitch and a few other options. i do not know if that is messing it up. if i change back to raw device, the file prints and the pitch is changed. Do you know of any way to control the form-feed on the raw device. i will take any solutions that will fix by printing issues.
Please try 0.6.47.3.22-1 from ftp://people.redhat.com/twaugh/tmp/redhat-config-printer/ Make sure to enable the 'Assume unknown data is text' option in the driver options tab. This should fix the problem with control codes that you noted.
i enabled the assume unknown data is text and that fixed the problem with the control codes. i would like to thank you for all help. clyde
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-473.html
Can anyone please tell me how to enable automatic form feed using "raw" printing? Thanks
i was never able to make the raw device formfeed. what i had to do was use the text only printing and enable the assume unkown text is data. then within that driver you able to control whether or not to form feed. we also had to update the os as noted above.