ALT Linux Bugzilla – #17558
printing on Okipage 8w Lite is troublesome
Last modified: 2014-11-05 20:16:46
You need to
before you can comment on or make changes to this bug.
Created an attachment (id=2995) [details]
I configured CUPS for Okipage 8w Lite through the standard means (web
The printing is troublesome:
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 the printer. After
that, it printed the 3rd page from my job. So, I was missing the 2nd one. Then
I sent it as another job to the printer, but again it was on fire or like that,
and the job got lost. So, I sent this page once more after resetting the
printer, and finally it was printed, and I had all 3 wanted pages.
Perhaps, oki4drv (http://www.openprinting.org/show_driver.cgi?driver=oki4drv )
would work than oki4w
) better in my case... (or not).
I have also posted this description at
Fedora and Mandriva have/used to have a special daemon for these printers:
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:
(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).
$ rpm -qf /usr/share/printer-testpages/photo-testpage.jpg
$ 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
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, перевесить на
текущие ветки или сизиф.