When I attempt to send a print job from a NT workstation to our Canon
imageRunner 5000 copier/printer I get a garbled mess. Printing from an XP
box gives me correct output. Setting print commands to "lpr -r -l -P'%p' %s"
gives exact same results. However, if I print to a file and then issue the
same command from the server terminal I get correct output (substituting the
variables for actual values). Printing directly to the IP address of the
printer from NT (using the same driver) gives correct output also.
I also have this problem.
We recently acquired a Canon ImageRunner iR5000i. The machine is supplied with
drivers for various versions of Windows. I set it up in exactly the same way as
all my (working) HP printers are set up, by installing the Canon PCL6 driver on
the Samba (2.2.8a) server, and having Sambe invoke lpr from LPRng to print the
generated file. The printer would produce only a line of garbage at the top of
Installing the driver on an NT 4 server works as expected. Testing showed that
the PCL output generated by printing to file from a workstation was different,
according to whether the driver was on the Samba server or NT server. The file
generated using the driver on the NT server would print perfectly using LPRng
from Linux,but the one generated with a Samba hosted driver would not.
Canon also supply PCL5 and PostScript drivers for this machine - both of these
drivers showed similar results
. I assume this must be a bug somewhere in the Samba spoolss code that show up
with the Canon drivers.
comment = Canon ImageRunner 5000i in Print Room
path = /var/spool/smb_print
min print space = 10000
printable = Yes
print command = lpr -b -P%p %s
lpq command = /usr/bin/lpq -P%p
lprm command = /usr/bin/lprm -P%p %j
:cm=Canon iR5000i Network Copier:\
Have you initialized the driver on the Samba server?
Can you send me a level 10 debug log of the failure?
Also, can you be more specific about the differences
between the PCL files generated by printing to an NT
server and to a Samba server?
Finally, does this only affect the Canon driver? Or
are other drivers giving similar results?
Created attachment 99 [details]
Print file with workstation set to print directly to IP of printer.
Created attachment 100 [details]
Print file with workstation set to print through Samba server
I'm not sure I know what you mean by "initialize the driver on the Samba
server". One note, if I change to a different driver (HP Laserjet 4V) and
print through the samba server to the Canon printer, output works great, we
just can't use the advanced functionality of the printer.
Level 10 logs are coming...
In my case, this affects only the Canon driver. I have drivers on the Samba
server in question for HP8100DN, HP4500C, HP2100TN, HP2200DN, HP4MV, and HP 4
printers. All of these work flawlessly.
It's also worth noting that it seems perfectly possible to print to the Canon
iR5000i via Samba, as long as you dont use the Canon driver. PCL for HP4
printers seems to work, as does plain text. Of course you need the Canon driver
to get access to most of the functionality of the machine...
Created attachment 101 [details]
Level 10 debug log
This is a debug log of an NT workstation opening the printer dialog box and
hitting the "Print Test Page" button. I noticed a bunch of buffer overflows as
I went through it.
If you mean the WERR_INSUFFICIENT_BUFFER return code,
that is normal. We tell the client to expect a larger
buffer that what it previously indicated.
This bug is soundiing more and more like a driver issue.
Can you set the NT printer server that was working to
use on RAW printing? (goto the printer propteries
on NT server and select the "print processor" button
off thw front tab. Then check "Always spool RAW datatype").
My guess is that the driver only supports EMF printing
(server side rendering) and can't handle RAW printing,
If this is the case, you should get the same garbled
output through the NT print server this time.
On my Win2k server I looked at the properties of the printer and the print
processor was already set to raw. Also, I would expect that if that were the
problem to not occur on Windows XP workstations.
This is different. On a win2k/xp server you have to
uncheck the "Enable advanced printing features" box
on the Advanced tab of the printer properties.
On the Win2k server:
1. Uncheck the "Enable adavanced printing features"
2. Set print processor to RAW (already was).
3. Ok, Ok, Ok.
On the WinNT workstation:
1. Right click on printer and select properties.
2. Click "Print Test Page"
Output was still good. Same results for WinXP workstation.
Thought of something to add...
I am nearly 100% positive that this driver does not require server side. I
used to have this printer on a Novell network with the Novell server acting as
a print queue. Through this setup, all worked quite well.
What is the exact name of the driver installed?
Is it s aPCL 6 driver? I'm really fishing here
since I'm not sure where to go with this one.
closing as either a driver issue or an EMF vs. RAW issue.
No point in keeping bugs open that we are going to work on.
originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.
I added one of the early comments to this bug back in 2003. Since then, I've
learned a few things that may be worth adding to this.
Canon use a proprietary communication protocol to communicate with their
multifunction devices. This protocol is called CPCA (Common Peripheral
Controlling Architecture), and supporting it is necessary for all advanced
features. Canon provide PPD files for most of these devices, but while the PPD
and a spooler like CUPS will allow printing, it does not allow you to use many
of the features available. There is a little information about CPCA available
CPCA uses tcp/515 and udp/47545, which suggests to me is a just an addon to
standard lpr type printing.
Anyway, it seems that any Canon devices that require CPCA support use a library
from Canon that doesn't work with Samba, due (I suspect) to this being rather
non-standard. As such, if you want to use one of these devices on a Samba
server, you have to install the driver locally on the Windows workstations. If
you don't want to suffer this, I'd currently suggest not buying these devices.