OKI4DRV(l) OKI4DRV(l)
NNAAMMEE
ookkii44ddrrvv - User space based driver for OOKKIIPPAAGGEE 44ww and
OOKKIIPPAAGGEE 44ww PPLLUUSS printers.
SSYYNNTTAAXX
ookkii44ddrrvv [_-_g_m_v_V] [_-_s papersize] [_-_o output] [_-_d darkness]
[_-_w paperweight] [[_f_i_l_e]_._._.]
DDEESSCCRRIIPPTTIIOONN
ookkii44ddrrvv is a user level driver for the OOKKIIAAPPGGEE 44ww and
OOKKIIPPAAGGEE 44ww PPLLUUSS GDI printers.
It takes PostScript input from some files specified on the
command line or from standard input and renders them
through GhostScript's raw _b_i_t device. The GhostScript
output will be coded into a data stream apprioprite for
those printers and spooled page by page sended driectly to
the printer device itself. The default printer device file
used is: _/_d_e_v_/_l_p_0.
WWAARRNNIINNGG!!
Due to the printing technology involved the feeding of the
printer with data imposes some real-time constraints on
the run of this program. The document processing must
therefore be done on a page by page basis. The host system
should be ffaaiirrllyy wweellll equipped to keep up with the print
ers hunger for data. Supposedly an 486 with about 16M
bytes of RAM should do it. But please ddoonn''tt try to use
this program with one of those printers on an in esp.
386SX/16MHz with 4 megs of RAM! I'm personaly using an
K6/333MHz with 64M bytes of RAM and can't therefore tell
what the real lower limit is.
However: bbee wwaarrnneedd!! Failing to meet those constraints may
result in severe physical demange to the printer! Tought
it shouldn't, since I have beed observing those printers
ability to stop and resume in the middle of processing a
sheet of paper. It appears that this behaviour involves
some control from the computers side, so I can't really at
this stage reproduce it.
Due to spooling of whole data pages in the raw format used
by the printer itself You will need at least about 64M
bytes of free disk space too.
PPlleeaassee mmaakkee ssuurree tthhaatt tthhee pprriinntteerr iiss sseett ttoo EEPPPP oorr SSPPPP
mmooddee iinn tthhee BBIIOOSS!! ECP will fail for reasons I don't want
to explain in lenght here.
To guarantee a quite continuous data streem, the process
of sending the page image data to the printer is exploring
real time and execution priority manipulation facilities
of the underlying operating system. As a consequence this
15 Mai 1999 1
OKI4DRV(l) OKI4DRV(l)
program must be used in SSUUIIDD rroooott mode. The second conse
quence of this is that it doesn't make sense to use this
program in pure filtering mode under the control of some
systems printer spooling daemon like for example: llppdd.
Sorry but that's just like the live is. However the user's
inconvennience should remain quite moderate.
If you expierence problems try first to output the data
into a separate file and thereafter to cat it to the
printner at once like this:
oki4drv foo.ps -o temp; cat temp > /dev/lp0.
OOPPTTIIOONNSS
The options recognized by this program are:
--gg Render in graphics mode instead of text mode, which
is the default.
--mm Use the manual paper feed instead of the default
automatic.
--ss _p_a_p_e_r_s_i_z_e
Specify the paper size. Possible values are:
_a_4,_a_5,_a_6,_b_5,_l_e_t_t_e_r,_l_e_g_a_l The default value is EEuurroo
ppeeaann a4.
--oo _/_d_e_v_/_f_o_o
Specify and alternative printer device file name or
any file if you wish to cat the data to the printer
after fully finished rendering. The default value
is: /dev/lp0.
--dd _d_a_r_k_n_e_s_s
Specify the darkness value in the range from -2 to
2, from dark to light. 0 (medium) is the default
value.
--ww _w_e_i_g_h_t
Specify the paper wieght in the range from -2 to 2,
from heavy to light. 0 (heavy) is the default
value.
--vv Prints the version information and exit.
--VV Run in verbose mode diving information about run
ning status and currently processed pages in a for
mat similiar to the one used by the TeX tools.
RREEQQUUIIRREEMMEENNTTSS
You will need the excellent GhostScript interpreter for
the PostScript language to use this program.
15 Mai 1999 2
OKI4DRV(l) OKI4DRV(l)
BBUUGGSS
There are currently no known bugs in the driver program
itself, other then of linguistic nature in comments and
documentation. The only bogousity accounts go to OKIDATA -
which didn't give me _a_n_y documentation about the protocols
used by those printers!
However with the latest 2.0.3x series of kernels there
appear to be some bogous workarounds for bugs in the
interface protocol handling, which are preventing this
driver from working properly. Recent 2.2 (namely 2.2.9)
work fine again.
AAUUTTHHOORR
Marcin Dalecki <dalecki@cs.net.pl> (- constant contact) or
<dalecki@dacotec.net> (- current job).
15 Mai 1999 3
