>Hi Dragan ,
>
>Currently the VFP and Word output goes to PDF files on disk without dialogs using Amyuni 2.06 but, for reasons explained elsewhere, I need a new solution--and I'd like one that doesn't require extensive rework of the application. The user can choose to print to paper or PDF from any number of places. Printing is handled by an automation class. Immediately after printing to PDF, the files should appear in the user's personal application output directory so they can email them to the client if they wish. I'd really like to keep the print process self-contained if possible. There can be up to 6 documents printed as a batch. All come from Word except the second in the sequence which is a VFP report. The documents don't need to be combined, at least not yet--but one might guess that will be the next task :-)

The printjob solution would still work; you could just pass all six requests as a batch, so to make sure all six are processed together. The moment the user clicks on "I want a PDF" it would go there instead of the old way.

>In addition to the comment about the GS process being slow on TS, I found a comment elsewhere that GS balks at long filenames.

I didn't have that problem, with GS 8.11 (the one which comes with Print2Pdf) and I've run tests on hundreds of .doc files with really long filenames. But even if something may cause such a problem, it's easily circumvented by telling GS to output to a sys(2015)+".pdf", then rename using a FileSystemObject or some API (so VFP's funky handling of upper/lower doesn't get a chance).

>That could be a real show-stopper for us IF it is true. Both of these firms pretty much run on the file naming conventons we've established; it would be very difficult to change them now. I downloaded and installed the Adobe PS driver and GS last week but can't figure out to use them. I also don't know how to install or configure them within the clilent's environment, but that is a separate issue to be addressed after I determine that the solution works! I downloaded Print2PDF about 6 months ago; it was interesting but couldn't handle output from Word and appeared to be a bit bulky for what I want to do.

Like I said, I had to fiddle with it - basically, wrote a wrapper - to make it work with Word. The critical part:

			DO CASE
				CASE .VERSION="11"
					.Documents.Opennorepairdialog(lcgetfile,.F.,.T.)
				CASE .VERSION="10"
* the enteenth parameter .f. is the "open and don't try to repair", I assume.
					.Documents.OPEN( lcgetfile,.F.,.T.,.F.,,,,,,,,,.F.,,.T.)
				OTHERWISE
*-- we don't know the parameters
					.Documents.OPEN( lcgetfile)
			ENDCASE
*-- UT message #1217431 - Don't set the printer unless we have to, as it can take a few seconds.
			IF NOT .ActivePrinter=lcPrinter
				.ActivePrinter=lcPrinter
			ENDIF
			loDoc=.ActiveDocument
			WITH loDoc AS WORD.DOCUMENT
				.PrintOut(,,,lcPS)      && our .ps file, fullpath
			ENDWITH
			loP2P.waitforfile(lcPS)       && loop to wait until file is closed - uses fopen()
			loP2P.cOutputFile=tcTargetFile
			loP2P.makepdf()

>This weekend, I've examined 9 different PDF solutions from 7 different vendors. Seven of these products have been deemed unsuitable for various reasons, and the jury is still out on the other two. I'd be more than willing to test the ps/gs solution if I knew how to make it work. I included some test code in the previous message to Edgar. How would I plug in them in? I tried setting the ActivePrinter to 'Generic PostScript Printer' but the ps file goes to print, not to file.

When setting the printer, you have to direct it to FILE: port. Not too late: go to your printer settings and instead of LPT1: or what have you, set it to FILE:.