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