[cups.general] very strange dot-matrix printer problem: randomly wrong print result (ghostscript-esc p2)

Wed Sep 13 01:17:08 PDT 2006

Hello,

On Sep 13 12:25 ??? wrote (shortened):
> ... dot-matrix printer ... Epson LQ-300K
> 
> 1) both LQ-24 driver and LQ-570+ driver (in SuSE 10.1. Actually they are
> all using 'epson' driver in ghostscript) work correctly once they
> installed. All resolutions supported by printer works (except 360x180
> which I didn't test because I never need to use this resolution). The
> result is correct for all of PDF file, OpenOffice docs, images and plain
> text documents.

This shows that the driver is the right one and that the printing
system (i.e. CUPS and its filters) is set up correctly.

> 2) if I print Novel test page right after installed it in cups, 
>      1. the novel test page only print the upper 1/5 section
>      2. then eject paper, asking for another piece of paper
>      3. print some junk text on it ...
....
> 3) sometimes, novel test page can be printed correctly
....
> 5) Sometimes, a wrong page is printed even if I don't print novel test
> page, but some normal document. Once printer ever produced a wrong page,
> it will never get any following page / jobs correct ...

This shows that the reason is not the test page.

Once there is whatever error in data trasmission to the printer,
the printer does no longer understand the actual meaning of the
bytes which it receives and this leads to random results.

> ... if I use OMNI driver, the print result is far from
> correct (much much worse then ghostscript)

In general the actual printout results of the OMNI driver
are often (perhaps almost always) inferior to the results
of other Ghostscript drivers.
This is the reason why the OMNI driver is not recommended.
The OMNI driver is theoretically a good idea but actually
the other more model-specific Ghostscript drivers result
better printouts.

> What really make me feel strange is that it seems the printer driver
> could "remember" when it enter "print wrong page mode", e.g. it can
> produce 100 pages correctly, once it produced a single wrong page, it
> will always produce wrong page, even if we ask it to print the pages it
> had printed correctly.

It is the printer which "remembers" it.
Actually the printer does not "remember" a "wrong page mode" but once
it is in an "confused" state because of whatever data transfer error,
you must do a hard reset of the printer (switch it off) and stop
the currently active print job (in particular the active CUPS backend)
and then switch the printer on again to get back to a clean
state, see our documentation:
/usr/share/doc/manual/suselinux-manual_en/manual/sec.drucken.prob.html
-------------------------------------------------------------------------
11.7.8. Defective Print Jobs and Data Transfer Errors

Print jobs remain in the queues and printing resumes if you switch the
printer off and on or shut down and reboot the computer during the
printing process.
Defective print jobs must be removed from the queue with cancel.
If a print job is defective or an error occurs in the communication
between the host and the printer, the printer prints numerous sheets
of paper with unintelligible characters, because it is unable to process
the data correctly.
To deal with this, follow these steps:
1.
To stop printing, remove all paper from ink jet printers or open the paper
trays of laser printers. High-quality printers have a button for canceling
the current printout.
2.
The print job may still be in the queue, because jobs are only removed
after they are sent completely to the printer. Use
lpstat -o
or
lpstat -h print-server -o
to check which queue is currently printing. Delete the print job with
cancel queue-jobnumber
or
cancel -h print-server queue-jobnumber.
3.
Some data may still be transferred to the printer even though the print
job has been deleted from the queue. Check if a CUPS back-end process
is still running for the respective queue and terminate it.
For example, for a printer connected to the parallel port, the command
fuser -k /dev/lp0
can be used to terminate all processes that are still accessing the printer
(more precisely: the parallel port).
4.
Reset the printer completely by switching it off for some time.
Then insert the paper and turn on the printer. 
-------------------------------------------------------------------------
By the way:
Regarding the question "why does the backend keep running?", see
http://lists.suse.com/archive/suse-linux-e/2006-May/1077.html

I assume your printer is connected via the parallel port.

The data transfer errors may happen because of an inappropriate
mode for your parallel port in the BIOS of your computer
(i.e. your parallel port mode is inappropriate for your printer).

There are some bug reports about problems with the parallel port
in our Novell/Suse Bugzilla. A good report to start is
https://bugzilla.novell.com/show_bug.cgi?id=185135
See also the other bug reports which are mentioned there.

Something is fishy with the parallel port stuff in the kernels
since Suse Linux 10.0, see
http://lists.suse.com/archive/suse-linux-e/2005-Nov/1206.html

The current workaround is to experiment with various BIOS settings
and explicite additional settings in /etc/modprobe.conf to find a
setup, which actually works in a particular problematic case.

By the way:
Your printer is a dot matrix printer.
Do you really want to print in graphics mode with it?
If not, you should have a look at
http://en.opensuse.org/SDB:Using_Your_Own_Filters_to_Print_with_CUPS
"Printing Plain ASCII Text in Printer-Specific Code"

Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix at suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/