The driver you link to is the same version as supplied from the vendor's site and is indeed the driver we are using to print with.
Thanks for the clarification - it wasn't clear from your earlier statement and I didn't want to make the assumption. Now I have to rethink...
Have you used the custom PPD?
Have you tried the "postscript-lanier" driver?
To me, this problem seems less about our set up and more about ghostscripts handling of large images and certain advanced features in PDFs.
gs is creating files consistent with what you see in the printer job queue, which suggests that the driver is converting files to postscript for printing.
Have you tried converting direct to postscript first, and printing that? (Pedantic I know, since pdf2ps uses ghostscript.) On a related note - convert the PDF into some single-layer format before printing then ghostscripts handling of PDF becomes irrelevant.
You'll still get big files - make no mistake. eg.
$ pdf2ps IMG.pdf
$ ls -l IMG*
-rw-r--r-- 1 simon simon 344102 2010-02-17 21:47 IMG.pdf
-rw-r--r-- 1 simon simon 29783750 2010-02-18 19:11 IMG.ps
So the file increases by 100x - and this is a single page invoice, mostly white space, created by scanning the paper page to a jpeg then putting the jpeg through adobe acrobat. (All too common occurrence.)
But when I hit file > print in evince, while watching the print queue, then I see the job size as 1803k - eg, only about 10x the original file size. (But, my printer is an hp.)
This is partly why I wonder about the postscript-lanier driver - it is possible that it contains postscript-specific optimisations for this printer.
The next question that comes up, then, is "what is windows doing?" to be sending
a size only fractionally bigger than the source document
It is certainly not sending ps data to the printer!
Possibly there are legal reasons that linux cannot use the same method as windows? That would be typical.
The reason this is so important to 'us' is because we're looking to change from being a Microsoft business to an open source one - not only because its cheap, but because we value open source and want to give back. But there are a few barriers, like this one, that would greatly inhibit our day to day procedures.
This perspective is very important - it changes the sort of advise I give you.
Moving from a proprietary to an open shop is a big deal and should be done by increments - I do this professionally.
It may be that you will ultimately have to consider changing some of your hardware, as well as your day-to-day operations, to suit the new (FOSS) paradigms. Businesses that do this (though I have been personally involved mostly in public sector migrations) usually experience a 10-20% increase in productivity in 18 months, though there is an unpredictable decrease in the short term (1-3months). Disasters are usually a matter of staff resistance.
It is unusual for businesses to be in a position to change a printer just on principle. Since you already own windows licenses, it is likely that any such decision can be put off until you'd normally replace it from attrition. You'd do this by dedicating a windows box as a print server. You send the file to windows and windows prints it. This will be very similar to what you do now.
However, it may be that pre-processing the large files you need to print will minimise the inconvenience without compromising quality.