We have been using our customized driver in production, but there appears to be a problem with job isolation that affects more than just shared terminal servers. All operating systems are affected and we don't know how to fix it. We understand the support options, but at least we want to know if the problem is solvable before spending more money on a product that isn't working.
If user prints multiple print jobs into the queue, emfcreator gets executed but instead of processing only one spool file into a job, it processes ALL spool files and merges them ALL into one job. The parameter bWaitUntilPreviousExeExit=1 doesn't seem to matter.
This is a serious problem because pages from two unrelated print jobs get combined and the user only sees one call to our application.
Easiest way to reproduce without running a printing application is to
(a) Pause the VeryPDF Printer Queue, (b) Send a number of print jobs (even test pages work) that will create 2 or more distinct entries in the spool queue for the printer, (c) Unpause the queue. Observe that all jobs are processed by emfcreator at one time and the RunExe only gets called once for all the pages combined as if they were all printed at once.
We can grant you access to sandboxed test servers, but it looks like you should be able to easily reproduce this problem on your own computers.
Please let me know what you find out.
Thanks for your message, this problem can be solved in a custom-build version of mini EMF Printer, we will disable "Auto merge all print jobs into one print job" in this custom-build version of mini EMF Printer product, the all print jobs will be processed one by one, one print job will call one instance of EMFCREATOR.EXE application to create EMF files, for example, if you send 10 print jobs to mini EMF Printer, mini EMF Printer will call EMFCREATOR.EXE 10 times, we think this solution will solve this problem to you, if you are interest in this solution, please feel free to let us know.