by Justin Yackoski - (my email address is my first name @ my last name dot name)
People who have at least 1 windows PC (or a windows VM), and 1 or more linux PCs connected via a network. This HOWTO assumes that the printer is connected to the windows PC, the windows PC is always on, and the printer is properly installed on the windows PC.
Without this method, your printer must be supported under linux to be able to print to it from linux, even if it is attached to a windows PC and you want to print to it via SMB. So, in theory, as long as you have a windows PC on your network to connect your printer(s) to, you can print to ANY printer regardless of its support for linux. I've tested this setup with an HP LaserJet 5L (which is normally supported by linux), and a Canon imageCLASS MF3110 (which is NOT at all supported by linux as of this writing). Note that the only change needed to switch between printers is to change the default printer on the windows PC.
Yes, you could instead try RedMon at http://pages.cs.wisc.edu/~ghost/redmon/ but you're on your own there.
The windows PC is not going to actually share its printer via SMB. Instead, a directory will be shared, which will be used as the spool/dropbox directory.
First, create a user via the windows control panel. In this example, the username is "print" and the password is "print". You should use a better password.
Second, create a directory to share. In this example, I'm using c:\temp\spool and assuming your windows PC's name is windows_pc
Third, share the directory and give the print use you created in step 1 full control over it
Test that you can access the share from the linux PC via smbclient. I.e., run: smbclient //windows_pc/spool -U print and make sure you can put a file into that shared directory
Next we need the dirwatch.py script, available from here dirwatch.py. Save it somewhere, i.e., in c:\scripts\dirwatch.py. Make sure you rename it to dirwatch.py (I've named it dirwatch.txt so my web server doesn't try to execute it!) The dirwatch script is based on Tim Golden's great example available at http://tgolden.sc.sabren.com/python/win32_how_do_i/watch_directory_for_changes.html
Edit the dirwatch.py script and make the following changes:
-color option there unless you have problems. This option enables 24-bit greyscale, instead of 8-bit.Run the dirwatch script by double-clicking on it. A window will open up that shows its output
Test the dirwatch script by using smbclient (as described above) to PUT and then RENAME a postscript file (with a .ps extension) into your spool share. If things are working properly, the .ps file will be printed out on your printer, and you should see output on the python terminal window on the windows PC
NOTE: The dirwatch script will only recognize files when they are RENAMED, so you must first creating a file in the directory you specified in the path_to_watch variable , and then rename it.
Now that the dirwatch script is working, kill the script that is running. Rename dirwatch.py to dirwatch.pyw. With a .pyw extension, no console window will open when its run.
Run the new dirwatch.pyw script and place a shortcut to it in your windows startup folder so it is run automatically at boot
NOTE: If you ever notice things are being printed out multiple times, it is likely that 2 or more copies of the dirwatch.pyw script are running. Go to the windows task manager and kill all but one of the pythonw.exe processes. This should fix the problem.
The Windows PC is now fully setup.
The Adobe distiller PPD must be installed where CUPS keeps its PPDs. The distiller PPD is named ADIST5.PPD and is in the zip file available at http://www.adobe.com/support/downloads/273e.htm
Extract ADIST5.PPD and put it in CUPS' PPD location. Generally, this is /usr/share/cups/model/. You should also rename it to lowercase, adist5.ppd.
Download the winp script from winp. Make it executable, and put it where CUPS keeps its backend scripts, usually /usr/lib/cups/backend/. The winp script is a modification of the pdfdistiller script by Michael Goffioul
Create a spool directory on your linux filesystem for the winp script to use. In this example, I use /var/spool/winp. Then, ensure that this directory is writable by the user that CUPS runs as, usually belonging to the group lp. Assuming CUPS runs as a user in the lp group, this can be accomplished by running chgrp lp /var/spool/winp and chmod g+w /var/spool/winp. If you're not sure what user CUPS runs as, run ps auxw | grep cupsd. The user (first column) listed for the cupsd process is what you should use as the first argument to the chgrp command.
NOTE: This is a SEPARATE spool dir on the linux PC. Not the one the windows PC is sharing. This one is just some local temporary space to work in
Edit the winp script and make the following changes:
/var/spool/winpprintprintRestart CUPS so it recognizes the new winp backend script.
Now, create a new CUPS printer that uses the winp backend and the adobe distiller, by executing the following as root: lpadmin -p windows_printer -E -v winp://windows_pc/spool -m adist5.ppd Note that adist5.ppd is case-sensitive, so we assume you renamed it to lowercase. windows_printer is the name for your new printer, and you should replace //windows_pc/spool with the name of your windows PC and the name you picked for the spool dir that the windows PC is sharing. Don't forget the winp: in the beginning.
Try printing to your new CUPS printer. Hopefully it will work!. If not, check the CUPS error log, usually in /var/log/cups/ (try turning up the log level in CUPS and restarting CUPS), or the winp log at /tmp/winp.log. One of these 2 places should help diagnose the problem.
If you have trouble using gsprint, notice print quality problems, or find that printing uses up a lot of CPU/memory on your windows PC, try the instructions in this section.
I found that using ghostscript on the windows PC to do the printing results in slightly different quality. Sometimes the acrobat-based printouts had some very slight alignment problems, where the filled-in areas of an object were just slightly off from the outline (you have to look very close to notice). Other times, ghostscript was slightly better (again, you have to look closely). Additionally, to use acrobat, you have to first convert the file to a PDF, which adds some processing time (and more chances for things to get mucked around during the conversion). Finally, if you use acrobat, whenever someone prints to the windows printer, an acrobat window will appear on the taskbar. It'll be minimized, and goes away on its own, but it does grab the focus.
Speed/memory-wise, Acrobat clearly excels here. I'm not sure if its because of processing PDFs instead of bigger PS files, or what. If your windows PC is slow or has limited memory, the Acrobat option may be better for you.
At any rate, if you'd rather have the windows pc use acrobat instead of gsprint, grab the winp-pdf script here winp-pdf, and edit it the same way as described above under the winp script section. Be sure to specify winp-pdf as the protocol instead of just winp when doing the CUPS printer setup step, or rename the script to winp and edit the line where PDFDIR is set to not have "-pdf" in it. Also, edit the dirwatch.py script and uncomment the line with acrord32.exe in it, and commend out the one with gsprint.exe in it. Also, you'll need to get the gdputil.exe file and put it on your path someplace (i.e., in c:\winnt\system32) available from http://www.watchdirectory.net/watchDir/GdPUtil.html.
Several people have written me with tips/suggestions on how to fix problems they've encountered. If you've fixed something or improved something that you think other people would benefit from knowing about, please email me and I'll add it here.
If you've got a problem where when you try to print with CUPS the files aren't showing up in the share on your windows PC, try turning up the logging level in CUPS. To do this, change the LogLevel specified in the cupsd.conf file (usually in /etc/cups/) to debug, and then restart CUPS.
If you find that when smbclient is run, smbclient is unable to find the windows PC, you can try using the IP address instead (assuming the windows PC has a static IP). If that works, when running the lpadmin command, use the IP address instead of the name of the windows PC, e.g.: lpadmin -p windows_printer -E -v winp://192.168.0.102/spool -m adist5.ppd
If you can't connect to the Samba server and can't figure out why, your firewall may be the problem. Note that you may have a firewall on BOTH your linux and windows computer by default, and you'll (possibly) have to modify them both!
The SMB protocol needs ports 135 and 139 allowed for TCP, and 137 and 138 allowed for UDP. On your windows computer, you should add your linux PC as a trusted IP or network, and vice versa. Also make sure broadcasts are allowed. In linux, you need to set FW_TRUSTED_NETS and FW_ALLOW_FW_BROADCAST_EXT to accomplish these two things, see HowTo Firewall Linux and Windows Hosts in a SOHO LAN for more info. Note that I don't have firewalls on my computers because I'm behind a NAT, and my Windows XP PC (upgraded from 2000, so maybe the settings are non-default) didn't have any trouble with this, so I can't offer much more advice besides what I've already mentioned.
Does a ghostscript window pop up on the windows PC at all? If the file is being deleted, then everything is probably working properly except for the program being run on the windows PC to actually do the printing. There are a couple things to try:
Check the path to ghostscript within the dirwatch.py script. If the script has a .py extension, you should see a window containing any relevant errors.
Quickly copy the file out of the share folder before it is deleted, and try opening it on windows and on linux. If you can view it on linux but not on windows, or in one program but not the one being used to print it (I assume ghostscript), then it is a compatibility issue.
In this case, try printing from another application on linux, or try using my instructions for using PDFs. Some linux applications generate postscript that isn't quite standard-compliant or is unusual in some way. Firefox often does this, though I haven't tried recent versions.
If you can not even view the ps file on linux (try several ps viewers), then the ps file is probably corrupted. I would still try the PDF instructions, if that works, then it is a compatibility problem. If that doesn't work, then something else is setup wrong. Probably the ghostscript on the linux PC isn't working, o the CUPS printer setup was incorrect (using the wrong ppd file?), or some other error which should show up in the CUPS log.
An option is to use VirtualBox or similar to create a windows VM that is connected to the printer, instead of having a separate windows PC. In theory this is exactly the same. VirtualBox must be configured so that the windows VM sees the port (e.g. USB) the priner is connected to. I can't provide much help there. The VM must be started & running before you try to print. You can use the vboxprinter script to start/stop the VM at boot or otherwise, and configure windows to auto-login so everyting is ready to go.
Thanks to Andrew Stein for his troubleshooting tips and lots of feedback.
Thanks to those who have translated this HOWTO into other languages.
Thanks to Rene van Paassen for the virtualbox tips.