The place I work uses label printers extensively and several users needed to use the same set of printers. Moreover, all but one of these users' computers are laptops, meaning we cannot simply share the printer from a single user's computer or else the printer will be unavailable when the user takes their computer home. So, I grabbed an old desktop that was laying around and threw Debian on it, converting it into an ad-hoc print server. Our label printers are Zebras, for the most part, and they work beautifully on Linux. The hickups did not occur until I went to set up the printers on Windows.
CUPS as you may or may not be aware, uses the IPP protocol by default to handle all printing operations, whereas Windows uses, by default (and as usual), their own homegrown protocol. Windows XP does support IPP, but the confusion begins with the drivers. Obviously, the CUPS print server must have the printer's drivers set up to print. However, if you install the equivalent drivers on Windows with the printer drivers set up on CUPS, confusion reigns. In the case of the Zebra I was setting up, I got a beautiful print out of my label in ZPL, Zebra's internal printer language. Various other permutations resulted in various other types of garbage.
It turns out, what you need to do in a situation like this is to set up the printer in CUPS as normal. Then, on the Windows side, you set up the printer using the http:// address (not Samba, or any other option) of the form http://myserver:631/printers/myprinter. When you reach drivers, you use the MS Publisher Imagesetter driver under the brand Generic. This is Microsoft's PostScript driver (why doesn't PostScript or PS appear somewhere in that name?). So, what is happening is that the Windows spooler is accepting jobs, outputting them to PS. This PS is being sent to CUPS, which receives it over IPP, converts it into the native printer language (which may very well be PS), and everything is all happy and dandy.