Re: [Gimp-print-devel] ESP 750 MODEL_INIT

[Karl H. K. <kh...@kh...>]

On Sun, May 07, 2000 at 08:47:03PM -0400, sh...@al... wrote:
> 
> Can someone remind me, was there a reason the ESP 750 is MODEL_INIT_STANDARD
> rather than MODEL_INIT_900.  Were there bug reports of problems as _900?
> 
> I seem to have a vague recollection of something like this, but my brain
> seems to be accessing corrupted memory.  To much exposure to that great
> big burning hydrogen ball today.  Anybody else ever see that? ;)
> 
> It seems to work ok for me as _900, and it won't work without it over USB.

It looks like every USB printer after the stc740 requires some special
init sequence to "connect" the interpreter with the USB port. By default
it only accepts jobs from the parallel port. In my opinion it should not
be the print plugin's responsibility to do this. In theory you just can
send this string once per session - the printer will continue to accept
jobs via the USB I/F until you power it down. I can see two ways of
doing this outside the print plugin:

  - Use the usbd daemon to send "firmware" to the device. That's what it's
    supposed to be used for, it can sense a new device and can take the
    necessary steps to initialize it. In our case it could just send the
    init string to the printer.

  - Use an input filter in /etc/printcap to always send the init string before
    the actual print job. This has the advantage that you can connect two 
    different queues to the same printer: Once via the parallel port and the
    second one via the USB port.

My /etc/printcap contains the following line:
[...]
       :if=/var/spool/lpd/epson-usb/epson-filter:\   
[...]

The epson-filter contains the following:

#!/bin/bash
exec cat /var/spool/lpd/epson-usb/epson-usb-codes - 

... and the file epson-usb-code is attached to this mail. 

Hope this helps,

Karl Heinz

-- 
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net