Posted by Tom Fulton on November 14, 2005 at 09:43:18:
I have run several tests concerning PDF printing with PDFFactory and
can report the following:
1) In the Printer Properties/Printing Preferences/Settings there is a check-box for "Save as unique filename?". The default setting for this is that the box is checked. When an identical filename is encountered, an underscore followed by a serial number is appended. e.g. _1, _2, etc. For PDF/Email printing this can be a big issue as the default Comet filename if ObjectProgram + '@20@' + (TERM$) +
[999] where 999 is a three-digit number randomly selected and then incremented. So if a filename is generated in Comet that already
exists, PDFFactory appends the unique suffix to create the new PDF but Comet will grab the old document for transfer to the Email or for
(Document=...) purposes.
2) Unchecking the "Save as unique filename?" check-box will instruct
PDFFactory to erase the old version of the file and replace with the
new.
3) There are issues with #2 as described above. I wrote a program to loop 1 to 1000 writing out a PDF document to a Comet PDF printer
for each iteration, the document containing nothing more than the loop counter. I did this into an empty AutoSave folder. The results
were under 200 files! Looking into the documents it appeared to have picked up only around every fifth document. I then put a PAUSE
(18) after the printer close, cleared the folder and re-ran. This time I wound up with around 890 documents, which is what I expected.
At the end of the run I'd have PDF document [189] followed next by document [199] Document [189] had loop counter 997 and [199] had 999. By going back into the earlier created files I did find a [194] that had document 998.
My conclusion is that you should use PDF printing with the "Save as unique filename?" check-box unchecked and that you should use at least a half-second to one second pause ( PAUSE (9) or PAUSE (18) ) in order to insure that whatever buffering issue PDFFactory has is not encountered.