>Thanks for the code, and for the reminder about setting the printer drivers to output to file. I did do that on each one that supports it--usually without much success except for the Generic PostSript Printer. I'm glad to learn that GS may be able to handle long filenames. It makes it worth putting in more time on the solution. I can't help but wonder though if it is really wise to take a simple one-pass, two-line process and turn it into a complicated group of objects and methods just from a sustainability standpoint. Perhaps the complexity will diminish once I figure out how it works.

It will. The defaults are well set in Print2Pdf - I had to change just a couple, and the name of the printer driver may need some debugging, or you may just want to set the name of the one you have as the default. The .ddf file (or whatever, comes with the printer driver) needs to be navigated to while installing the PS driver, there's no textbox where to paste the filename - and for me it was a must, because the default driver I already had was black and white - not good enough for a medical app.

> We normally don't save any of the interim files; the only output we need is paper or pdf file.

I've set them to a somewhere in or below the temp folder, so I would at least know by looking at them whether I'm getting them right (not that I'm too capable of reading PostScript as text, it has just gone too far by now). Having a file of 612 bytes was a sure sign Word didn't produce it properly - one of margin errors or, in case of merged documents, a value missing, would be a sure sign that I'd be getting a blank PDF. Which I just log as "didn't succeed producing PDF" and go on. But I'm doing batch, unattended conversions, not with the user waiting.

>Of course, interim files can be erased after they are converted but it's more pfaffing around, as is having to rename the file or copy it to a different directory.

Rename to a different directory is much faster. Just try that.

> Free is good, but it comes with a price tag. And I can't help but wonder if this solution might not also be broken by Microsoft's updates. If so, that becomes my problem once again. At least with a purchased solution, the vendor is responsible for insuring that it continues to work in spite of Microsoft! But my clients don't have $1500 for at the moment so I guess I'll plunder onward :-)

Story is familiar :).

And the vendor's responsibility may cost you the price of an upgrade every couple of years - they can't keep the old versions up to date with latest Windowses, that's the job of the new versions... so they make some money again, and assume that you'll pass the cost to your customers.

>One question about the word print command: Have you tried setting background printing (the first parameter on the print command) false? I usually do that so Word doesn't blunder onward (and perhaps quit) before the print to file is complete Maybe .waitforfile wouldn't be needed?

Tried several things, but with background printing on, it would show the margins or values dialog... or it would think that it shows it, but being invisible would also mean the dialog is invisible, but still active and waiting for a keypress. IOW, Word is stuck waiting for input, and I wouldn't have a clue what was going on, until I found that (thanks to Naomi's passion for searching) if you keep the background printing off, it then suppresses those dialogs (!). Which is, IMO, ass backwards, but so is Word, what can we do.

>Do you have any idea what is required to get this working in the production environment? I don't have much cooperation from IT so it needs to be pretty much "turn key" from the client's point of view--for both the LAN and Terminal Server installs.

I've installed it on one server where they didn't have Word, so it wouldn't work, and on our server, where it all worked (and where I worked out the differences between Word 2003 and 2007); you'd need the privileges to install the printer driver. GS doesn't even have to be installed properly, it has one registry entry where it keeps the location of its dlls, but I think it can find them if they are at the default location. You'd need to have write and delete access to wherever your .ps and .pdf files go, and I guess GS would need similar access to its temp files, which would, I guess, be somewhere under user's temp files. IOW, nothing that you didn't already do this way or another.