Skip to content

Use PJL Output


PJL (Printer Job Language) is a standard for setting print job options and is supported by most printers. A subset of PJL commands that is not as widely supported as PJL in general can be used to tell the printer to send notifications when the job has been finished and how many pages were output. This information can be used for ensuring that the job has been output completely, and to resume jobs if the output was interrupted instead of starting from page one again. This can be done on a different printer if configured (page failover).

The PJL output is implemented as seal-pjl-checkout service.


Restrictions

Consider the following restrictions concerning the PJL output:

  • It only works if the printer supports notifications concerning the jobs and the output pages via the PJL protocol. The implementations of the printer manufacturers differ drastically in some cases. Some manufacturers do not support the necessary parts of the PJL specification at all, and there are differences in the notifictaions for individual pages. Even different printer models from the same manufacturer may differ.

  • SEAL Systems relies on the information replied by the printer. For some devices, the implementation is faulty or does not conform to the PJL specification.

  • There are printers which crash and have to be turned off and on when trying to work with PJL output.

  • Some printers return sheet numbers instead of page numbers as specified in the specification, so in duplex mode, they claim to have printed three pages when they have printed six pages. In such a case, the job will not be continued at the correct page.

  • In general, it cannot be guaranteed that jobs will be resumed at the exact page where an error occurred. In fact, in most cases several pages will be printed again. In case of a network failure, it can even happen that a job is printed completely because the printer had already received the complete job before the failure occurred, and is later printed partly again because PLOSSYS 5 never received the printer's notifications about the completion of later pages. The philosophy is to make sure that the job has been printed completely, but that could lead to multiple outputs in case of failures.

  • In duplex mode, resumed jobs will always start with odd pages to avoid problems with strange PJL implementations. With native jobs, PLOSSYS 5 does not have any information about the duplex mode. In this case, the jobs will always be resumed at an odd page.

  • Before using the PJL output method in production, you have to test each printer if it works as desired.

  • When printing many jobs one after the other, the performance is significantly worse than with other output methods because PLOSSYS 5 always waits until a job has actually been output at the printer before processing the next job. Normally, PLOSSYS 5 sends as many jobs as the printers memory can hold to the printer, and the printer outputs the job one by one. With PJL output, the next job is sent to the printer only after the first one has been completely output. So the printer does not know that another job is pending. Many printers then go into the sleep mode wake up again immediately, which can take up to a minute between the jobs.

  • Due to the restrictions mentioned above, SEAL Systems recommends the PJL output only if it is necessary to ensure that jobs have actually been output to the printer, or to avoid printing the complete job again after a failure.


Requirements

For configuring PJL output, easyPRIMA as of version 1.8.0 is required. To avoid problems that can occur in certain circumstances with older printer drivers, it is recommended to export all systems after updating to easyPRIMA 1.8.0 to make sure that the newest drivers are used.


Configuration

With each printer which uses PJL output, the connection printer key has to be specified as

"connection": "pjl://<printer>:9100"

Available options for the PJL output is checklevel which specifies the level of using the PJL protocol:

  • checklevel=full specifies full PJL support. This is the default if no check level has been specified.
  • checklevel=sync specifies restricted PJL support assuming that if a @PJL ECHO message sent at the end of a job is replied to PLOSSYS 5, the job was output completely.
  • checklevel=none specifies no PJL support. This is equal to the socket protocol.

Example - printer connection with pjl and restricted PJL support

connection: pjl://myprinter:9100?checklevel=sync

Hint - multiple queues

The PJL output does not work correctly with multiple queues using the same printer.


Service Keys

The following service keys are available for the seal-pjl-checkout service:

  • LAST_PAGE_SAVE_INTERVAL: Number of pages after which the number of output pages is written to the database regularly
  • PAGE_FAILOVER: An interrupted job is repeated starting at the page printed last or at the first page
  • PRINTER_RESPONSE_TIMEOUT: Time interval after which the connection to the printer is closed when the printer does not send any notifications (not even regular scheduled dummy notifications, i. e. printer has crashed)
  • PRINTER_PAGE_RESPONSE_TIMEOUT: Time interval after which the connection to the printer is closed when the printer does not send notifications about the number of printed pages. This will happen when there is a paper jam or when the printer is out of paper.

Each of the service keys can be specified specifically for each printer.


Printer-Specific Keys

The following printer-specific keys are available for the printers using PJL output:

Hint - caveats for printerPageResponseTimeout

A configured PRINTER_PAGE_RESPONSE_TIMEOUT or printerPageResponseTimeout, when triggered, will lead to PLOSSYS 5 setting the job to error status although the printer is still trying to print the job. PLOSSYS 5 will then repeat the job or send it to another queue if a virtual queue configuration applies. Then, jobs waiting in the queue for the printer will be sent. Many printers will not send back PJL notifications if they are currently printing another job, so the repeated job and the waiting jobs will quickly run into the printerResponseTimeout, be repeated as often as configured in JOB_MAX_POSTPONED_COUNT or jobMaxPostponedCount and then be set to error status, too. However, all these jobs and their repetitions have been sent to the printer (given enough printer memory or a hard disk), and when the current problem (e. g. paper jam) is fixed, the Sprinter will output them all. Still, the job state in PLOSSYS 5 will be error. Consider if this is what you need and how to sensibly configure the related settings before using this feature!


Back to top