From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
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
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
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):
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.
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
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
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]
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:
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
%%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
Please try 0.6.47.3.21-1 from
(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
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.
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.
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.