Bug 124250 - prints postscript as text on dot matrix printer
Summary: prints postscript as text on dot matrix printer
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: redhat-config-printer (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-25 02:29 UTC by Scott Burns
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-21 01:44:22 UTC
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-09 02:56 UTC, Scott Burns
no flags Details
Printer configured as LQ-2080 (2.69 KB, text/plain)
2004-06-09 02:57 UTC, Scott Burns
no flags Details
Test file (405 bytes, text/plain)
2004-06-09 02:57 UTC, 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 05:00:00 UTC

Description Scott Burns 2004-05-25 02:29:49 UTC
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 09:15:02 UTC
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 23:21:37 UTC
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 08:04:46 UTC
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-09 02:56:49 UTC
Created attachment 100982 [details]
Text only configuration

Comment 5 Scott Burns 2004-06-09 02:57:26 UTC
Created attachment 100983 [details]
Printer configured as LQ-2080

Comment 6 Scott Burns 2004-06-09 02:57:45 UTC
Created attachment 100984 [details]
Test file

Comment 7 Scott Burns 2004-06-09 02:58:29 UTC
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 16:31:21 UTC
(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 16:32:17 UTC
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 16:38:33 UTC
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 11:29:59 UTC
It would be great to have a RHEL 3 package, thanks!

Comment 16 Tim Waugh 2004-09-02 12:08:03 UTC
Please try from this location:


Comment 17 Scott Burns 2004-09-02 23:29:27 UTC
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 08:26:30 UTC
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 14:40:36 UTC
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 17:35:37 UTC
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 22:52:00 UTC
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 17:50:10 UTC
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 20:36:16 UTC
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 22:33:02 UTC
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 10:50:08 UTC
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 18:01:02 UTC
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-21 01:44:22 UTC
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 18:44:41 UTC
Can anyone please tell me how to enable automatic form feed 
using "raw" printing? Thanks

Comment 30 Clyde Sheldon 2005-03-15 19:12:17 UTC
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.