The issue is that this init string is needed *ONLY* if printing via the USB
port (and I believe it's not needed for the 740), not if printing via the
parallel port (this printer was working fine via the parallel port, I moved
it to USB because I have to connect a different printer to the parallel
port). This is why I considered this to be a USB issue.
Does anyone know if sending this code sequence to a 750 connected through
the parallel port will cause problems? If Linux applications that rasterize
directly instead of using GhostScript (like the GIMP) shouldn't need to know
what the printer interface is - only the type of printer. If I can print by
doing "cat file >/dev/lp0" and get output on a Stylus 750 connected to the
parallel port, I should get the same output if I do "cat file
>/dev/usb/usblp0" on the same printer connected to the USB port.
--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Vah! Denuone Latine loquebar? Me ineptum. Interdum modo elabitur.
-----Original Message-----
From: Karl Heinz Kremer [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 31, 2000 9:49 AM
To: [EMAIL PROTECTED]
Subject: RE: [linux-usb] Help with USB printer and usbdevfs
I am pretty sure that you don't have to do anything
special for a "raw" device exported to a windows
machine: I'm using an EPSON STC 740 with the USB
interface to print from several Linux machines plus
a vmware Windows session and sometimes from a real
Windows machine. I'm however still using the
2.3.39 backport to 2.2.14, which just worked and with
all the problems reported on the list regarding
printing I never bothered to update.
I'm not using any filter that adds any init codes
for every print job. This is what the driver on your
Windows machine will do for you, and the same goes
for GhostScript or the Gimp print plugin. These
packages usually reset the printer before they do
anything else.
Now in Beat's case, the string that's listed is exactly
this init string because he's modifying the UPP file,
which lists all the commands the printer needs, so he's
basically modifying GhostScript.
If you can print with one of the standard GhostScript
drivers you don't have to do anything special. If you
want to queue print jobs from Windows machines on
the net you don't have to do anything special either.
.. and you certainly don't want to modify printer.c
by adding functions that are not part of the USB
driver portion. As I said before, these init strings
are what the applications or drivers will generate.
If an application is not doing this talk to the
author of the software and fix the problem at the
correct level.
Does this explain this init string issue a bit?
Karl Heinz
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
