How It Works

When a print job is sent to the PDF Writer it will be handled by a Postscript printer driver. This driver sends the Postscript print job to the print queue. The print queue is handled by the Spooler service. Each PDF Writer print job is sent to a virtual printer port. The port will pick up the Postscript and convert it to a PDF or another type of document.

In order for the port to make the conversion from Postscript to a PDF or an image file format, it will need a converter. The most commonly used converter is Ghostscript. However, the PDF Writer can also use other converters such as the Normalizer from Datalogics.

The converter is not needed if you only wish to capture the raw postscript and do the processing or conversion yourself. This could be the case if you are redistributing the PDF Writer in a scenario where you upload the print jobs to a server on the Internet for later processing. Some Internet FAX solutions have been implemented that way.

If you want the PDF Write to output a PDF, PNG, JPEG, TIFF, EPS or other document type which is not Postscript then you need a converter installed. The converter must be installed on the same computer as the PDF Writer. Converters are not part of the bioPDF software and they have separate licensing models. Please read the license information on the converter that you plan to use or redistribute.

Technical Details

After reading the description above you should have a general idea of how the printer works. Let's have a closer look at some of the details.

Printer Port

During the installation of the virtual printer a new printer port is created. The new port is named BIOPDF and is implemented in the biopdf.dll. This DLL is located in the %SystemRoot%\System32 folder. On 64 bit operating systems this is a 64 bit DLL and on 32 bit operating systems it is a 32 bit DLL. The installer will detect the bitness of the operating system and install the correct edition of the DLL.

The gui.exe Process

When a print job is sent to the spooler, it is sent to the BIOPDF printer port. The port will save the Postscript to a file and launch the gui.exe process. One of the parameters passed to the gui.exe is the name of the postscript file. Another parameter is the name of the printer that created the print job on the spooler queue. The gui.exe process is launched in the user context of the printing user if possible. This means that the gui.exe process will have the security context of the user that created the print job. This allows the shown user interface to save files to the user's documents folder and other user specific folders.

Reading Configurations

When the gui.exe is launched it will read the configuration from the different ini files. The ini files contains settings that are default, global, user specific, and job specific. You can read more about these setting files in the documentation. Depending on the content of the ini files the gui.exe process will show an interactive dialog to the user or process the document without any user interaction.

Concurrency

During normal operation the printer has no problems with concurrency. It is designed to handle multiple users on Terminal and Citrix servers and will isolate the data belonging to each print job.

When using the runonce.ini file to control the printer there may be some concurrency considerations you need to be aware of. If two programs write runonce.ini files to the same printer at the same time then they will overwrite one of them. This will make the first print job pick up the only remaining runonce.ini file and the second print job will not see any runonce.ini file. To overcome this problem the gui.exe process will look for a runonce_documentname.ini file before it looks for the normal runonce.ini file. This can solve the concurrency problem but it requires that you have control of the document title when sending the print jobs to the spooler queue.

Another way to handle concurrency is to install two printers with different names. That will allow two processes to write documents to different printers and thereby avoiding overwriting each other's runonce.ini files. Keep in mind that you should wait for the resulting PDF or status file before sending the next job to the printer. Otherwise, you will end up overwriting the runonce.ini files for the used printer.