Printing a Label to a PDF Printer Does Not Create the PDF

Problem

One of the following occurs:

• Using a drop file in which the label is defined as Print-to-File displays Printed in the Loftware Print Server (LPS) Status Client, but does not create a PDF.
• Resending a print job from the Loftware Print Server (LPS) Status Client where the label is defined as Print-to-File does not create a PDF.

The Loftware Status Dialog displays the following symptoms.

• A: Jobs are shown as Processed.
• B: Your print jobs are listed as line items and the status is (M5492) Printed.
• C: There are no Critical Failures.
• D: The current device is selected in the Loftware Status Dialog.

Explanation

The same file name is being used for every print job. Windows attempts to "ask" the LPS for a unique file name or if it is acceptable to overwrite the existing file. However, the LPS is designed to run as a Windows service and cannot display dialog boxes, errors, or status information on the desktop.

This example uses the Bullzip PDF printer. Using <smarttitle> or <docname> macros in the File Name field causes Bullzip to use the same file name for every print job.

This list corresponds to the following screenshot.

• A: Available macros
• B: File name

The print request is sent to the Windows print spooler, and the LPS considers this to be a printed job.

Solution

1. To prevent this issue when using a Windows PDF printer to print your labels, insert a <time> macro with seconds as part of the file name. This ensures that each time you send a print job, the macro creates a unique file name for the PDF based on the time.
2. You can use the GUID macro for batch jobs that process and print within the same 60 seconds as the <time> macro is limited to a measure of every minute.

The following link provides step-by-step tutorial on how to set Bullzip so it does not interact with the desktop: Using Bullzip as a PDF Printer.

Other PDF printers may have other methods of creating unique filenames for the PDF file.