It takes PostScript input from some files specified on the command line or from standard input and renders them through GhostScript's raw bit device. The GhostScript output will be coded into a data stream appropriate for those printers and spooled page by page sendid directly to the printer device itself. The default printer device file used is: /dev/lp0.
WARNING!
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 fairly well equipped to keep up with the printers hunger for data. Supposedly an 486 with about 16M bytes of RAM should do it. But please don't try to use this program with one of those printers on an in esp. 386SX/16MHz with 4 megs of RAM! I'm personally using an K6/333MHz with 64M bytes of RAM and can't therefore tell what the real lower limit is.
However: be warned! Failing to meet those constraints may result in severe physical damage to the printer! Thought it shouldn't, since I have been observing those printers ability to stop and resume in the middle of processing a sheet of paper. It appears that this behavior involves some control from the computers side, so I can't really at this stage of developement reproduce it.
Please make sure that the printer is set to EPP or SPP mode in the BIOS! ECP will fail for reasons I don't want to explain in length here.
To guarantee a quite continuous data stream, 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 program must be used in SUID root mode. The second consequence 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: lpd. Instead you can use the "oki4daemon" to connect from your spooler over a named pipe into the soft realtime driver process. See README.oki4daemon in the distribution.
If you expirence problems try first to output the data into a separate file and thereafter to cat it to the printer at once like this:
oki4drv foo.ps -o temp; cat temp > /dev/lp0.
And make sure that the machine you are using is otherwise idle.
However please note that this is no longer true at all! They even prvided me for free with a recent model from them!
So all Linux/UNIX enthusiasts out there please note: OKIDATA is making fine printers for desktop usage, where it's really fine to use the power of the host CPU for the rendering of the data. They have IMHO the best price to performace ratio out there one can imagine!
With the latest 2.0.3x series of kernels there appear to be some bogus workarounds for bugs in the interface protocol handling, which are preventing this driver from working properly. Recent 2.2 (namely 2.2.9 and later) work fine again. I have only tested this driver release upon 2.2.9 as of now. If the situtation remains that the Linux printer driver once works and once fails again version by version, I will start to include a propper working driver in the package too.