This article is not intended to cover every reason that printing a label to a file may fail.
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.
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.
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.
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.