Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 124250 - prints postscript as text on dot matrix printer
prints postscript as text on dot matrix printer
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: redhat-config-printer (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2004-05-24 22:29 EDT by Scott Burns
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-20 20:44:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Text only configuration (2.25 KB, text/plain)
2004-06-08 22:56 EDT, Scott Burns
no flags Details
Printer configured as LQ-2080 (2.69 KB, text/plain)
2004-06-08 22:57 EDT, Scott Burns
no flags Details
Test file (405 bytes, text/plain)
2004-06-08 22:57 EDT, Scott Burns
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2004:473 normal SHIPPED_LIVE Updated redhat-config-printer packages 2004-12-20 00:00:00 EST

  None (edit)
Description Scott Burns 2004-05-24 22:29:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040124 MultiZilla/

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):

How reproducible:

Steps to Reproduce:
1.Configure a dot matrix printer simmilar to one shown above
2.Print a simple text document

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:
Comment 1 Tim Waugh 2004-05-25 05:15:02 EDT
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?
Comment 2 Scott Burns 2004-05-25 19:21:37 EDT
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
Comment 3 Tim Waugh 2004-05-26 04:04:46 EDT
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.
Comment 4 Scott Burns 2004-06-08 22:56:49 EDT
Created attachment 100982 [details]
Text only configuration
Comment 5 Scott Burns 2004-06-08 22:57:26 EDT
Created attachment 100983 [details]
Printer configured as LQ-2080
Comment 6 Scott Burns 2004-06-08 22:57:45 EDT
Created attachment 100984 [details]
Test file
Comment 7 Scott Burns 2004-06-08 22:58:29 EDT
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.
Comment 8 Tim Waugh 2004-06-24 12:31:21 EDT
(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.
Comment 9 Tim Waugh 2004-06-24 12:32:17 EDT
The main part of this (text-only printing) is redhat-config-printer's
fault, so I'm changing the component.
Comment 14 Tim Waugh 2004-08-13 12:38:33 EDT
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.
Comment 15 Pancrazio `ezio' de Mauro 2004-08-20 07:29:59 EDT
It would be great to have a RHEL 3 package, thanks!
Comment 16 Tim Waugh 2004-09-02 08:08:03 EDT
Please try from this location:

Comment 17 Scott Burns 2004-09-02 19:29:27 EDT
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?
Comment 18 Tim Waugh 2004-09-03 04:26:30 EDT
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!
Comment 19 Tim Waugh 2004-09-07 10:40:36 EDT
Does anyone have positive feedback about the experimental package, or doesn't it work for anyone but me?
Comment 20 Clyde Sheldon 2004-09-07 13:35:37 EDT
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.
Comment 21 Tim Waugh 2004-09-07 18:52:00 EDT
Please set the queue as a 'Text only printer' (it's the option next to
a raw print queue) -- this should now work.
Comment 22 Clyde Sheldon 2004-09-08 13:50:10 EDT
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
%%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
Comment 23 Tim Waugh 2004-09-08 16:36:16 EDT
I've found a problem that could explain that, and updated the test

Please try from


(You may have to change the queue trivially and click 'Apply' to get
it to regenerate the CUPS configuration.)
Comment 24 Clyde Sheldon 2004-09-08 18:33:02 EDT
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.
Comment 25 Tim Waugh 2004-09-10 06:50:08 EDT
Please try from


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.
Comment 26 Clyde Sheldon 2004-09-13 14:01:02 EDT
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.
Comment 28 John Flanagan 2004-12-20 20:44:22 EST
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.

Comment 29 Justin 2005-03-15 13:44:41 EST
Can anyone please tell me how to enable automatic form feed 
using "raw" printing? Thanks
Comment 30 Clyde Sheldon 2005-03-15 14:12:17 EST
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.

Note You need to log in before you can comment on or make changes to this bug.