Fedora and Mandriva have/used to have a special daemon for these printers: 

http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/printer-filters-utils/oki4w.startup
http://cvs.fedora.redhat.com/viewvc/devel/oki4linux/oki4linux.init?view=log

From description: A special daemon developed by Grant Taylor to \
#              support the OKI 4w and compatible winprinters. \
#              These printers have high requirements concerning \
#              timing and therefore one cannot use their driver \
#              directly out of a printer spooler (CUPS, LPD). To \
#              solve this problem, one lets the spooler send the \
#              job to this deamon. Activate this daemon when you \
#              have one of these printers and set up a CUPS queue \
#              for your printer with "oki4w_install".

This happens in installed Lite 4.0.3.

I see, there used to be oki4daemon in ALTLinux, too: https://bugzilla.altlinux.org/show_bug.cgi?id=1078 .

(In reply to comment #0)

> For example, I was going to print 3 pages from Firefox. At first, the printer printed the first page, then got stuck. So turned off and on

It's much much worse for JPEG images (it can be useful, say, for scanned texts). As a result of my observations, JPEGs should be considered unprintable with the currently supplied driver (in Lite 4.0.3).

For example:

$ rpm -qf /usr/share/printer-testpages/photo-testpage.jpg
printer-testpages-2.0-alt2
$  gqview /usr/share/printer-testpages/photo-testpage.jpg

and in the menu: "Файл" > "Напечатать"

The result: the printer prints an upper part of the image, and then is "on fire". It should be reset. The next attempt gives the same bad result.

I queued 6 jobs (to print this file) one after another. The result was: 3 good pages, 3 bad pages (only an upper part), intermixed, and sometimes with a long pause. (I did reset the printer when needed in the process.)

For another file with a scanned text, my attempts were even worse. Out of around 15 attempts, there was not a single good page! Mostly only an upper part was printed and it was displaced in the direction up.

I suspect that the design of the current driver is flawed: when this stupid printer expects a "real-time" reaction, the driver starts to do processing and is not on time. (And it's noticeable on pictures, because the processing of pictures takes more time.) It should do the processing before it starts talking to the printer. 

(In Windows, the work of the printer is not perfect (it requires  manual retries on some error conditions), but at least it prints all queued pages in complete form.)

There has been some experience of using this printer among ALT users: http://lists.altlinux.org/pipermail/community/2005-January/562243.html . I wonder whether they were able to achieve the relative stability of printing (as in Windows), so that I could try to repeat their success by trying different programs, or this printer has always worked very bad under linux.

В 4.0/branch исправления не будут вноситься уже технически (заглушена очередь на сборку), поэтому прошу ошибки, актуальные для sisyphus/p7/t7, перевесить на текущие ветки или сизиф.