How can jobs start printing even before spooling is complete

By /
Skip to main content

How can jobs start printing even before spooling is complete

How can jobs start printing even before spooling is complete

A large document can take a long time to spool. A detailed CAD drawing, a photo-heavy presentation or a long scanned PDF can spend minutes being written by the application before the job is complete. If a user has already walked to the printer to release it, that is a minute or more of standing and waiting.

Print Director does not wait for the whole file. Where the conditions below are met, a released job starts moving to the printer as soon as enough of it exists to print, and keeps flowing as the application writes the rest. The user gets pages out while their PC is still sending.

This guide explains what has to be true for that to happen, and how to tell, for a specific job, whether it printed early or waited.

How it works

Nothing in the path holds a complete copy before passing it on. Each stage forwards the bytes it has and keeps following the file as it grows:

  • The PDAgent begins capturing the job the moment the application starts writing. Once a few hundred bytes have arrived and the printer language has been identified, the job exists and can be acted on.
  • On a queue whose jobs wait on the PDServer, the PDAgent starts uploading immediately, while the job is still being written to it. The server writes what arrives into the waiting job’s spool file.
  • When the user releases the job at the printer, the release does not wait for the upload to finish. The PDServer starts sending to the printer from the part of the file it already has, and follows the rest as it lands.
  • On sites with more than one PDServer, a job held on one server and released at a printer managed by another transfers between the servers the same way, still while the original is arriving. All the legs run at once rather than one after another.
  • On Lexmark devices using download-print, the printer fetches the job from the PDServer itself and feeds it straight into its own print service as it downloads.

The practical effect is that the time a user waits at the printer is governed by how fast the printer can print, not by how long the application takes to finish sending.

“Starts printing” is not the same as “instantly”. The printer still has to interpret enough of the document to compose the first page, and some document types need more of the job than others before the first sheet can be marked. Early release removes the waiting for the file; it does not remove the printer’s own start-up time.

When a job waits for the complete file instead

Some Print Director features cannot be honoured against a partial job, because they depend on facts that are only known once the whole document has been read: how many pages it is, whether those pages are colour, whether they are duplex, and what paper they use.

Rather than guess, Print Director holds the job until it has finished arriving. That is the correct behaviour, not a fault, and it is what a customer is seeing if a large job does not start until spooling completes.

There are four conditions. If any one of them applies, the job waits.

1. The printer does not report its own jobs to Print Director

Print Director counts pages in one of two ways: from the print data as it interprets the job, or from the printer itself where an embedded Print Director application is tracking jobs on the device.

Counting from the print data needs the complete job, so those jobs cannot be released early. Early printing therefore requires a device with integration tracking enabled:

  • Lexmark devices with the embedded application and job tracking via the integration
  • Konica Minolta devices tracking via the enhanced server method
  • HP devices tracking via the statistics agent

Any printer receiving jobs without one of these arrangements will always wait for the complete file.

2. A print rule needs the job’s page facts

If a rule that applies to the releasing user at that printer depends on page counts, colour, duplex or paper group (for example “route colour jobs over 20 pages to the production device”, or “deny colour above a page threshold”), the rule cannot be evaluated against a job that has not been fully read. Those jobs wait.

Rules that do not depend on those facts do not hold the job.

Note that this is assessed per user and per device. A page-count rule that applies only to one department does not delay everyone else’s jobs.

3. The account being billed enforces a minimum balance

Where account billing is activated and the account being charged has Enforce minimum balance set, the job has to be priced before it can be allowed, and pricing needs the final page count. Those jobs wait for the complete file.

Accounts without a minimum balance are not affected.

4. The job has barely started, or its language is not recognised yet

Very early in a job there is not enough data to identify the printer language or to start sending anything meaningful. This clears within a fraction of a second on a normal job and is only visible for a job released at the instant it was submitted.

How to tell what happened for a given job

At the printer panel

While a job is still arriving and is not yet releasable, its row in the release list is marked with an hourglass instead of its document icon. Once the job can be released, the icon changes to the document type.

If a user selects an hourglass job, they are asked to try again shortly rather than being left with a silent failure.

In Resource Manager

Open the Waiting Jobs list. The Waiting column states the job’s current state in plain language, and where a job is being held for one of the four reasons above, it says which one. The wording maps directly onto the sections above, for example:

  • “Still being received: this printer counts pages from the print data, which needs the complete job.”
  • “Still being received: a print rule needs the job’s page counts, which are not known yet.”
  • “Still being received: account name enforces a minimum balance, so the job must be fully received before it can be priced.”
  • “Still being received: the printer language has not been recognised yet.”

Once the job becomes releasable the reason clears, so a job that shows no such text is not being held.

Getting the best result

If early printing matters at a site, aim the configuration at the four conditions:

  • Use devices with integration tracking. This is the condition that most often rules early printing out entirely, and it is the one with the clearest fix.
  • Scope page-fact rules narrowly. A rule that needs page counts should be assigned to the users and devices that actually need it, not applied broadly. A broadly applied page-count rule delays every large job at every printer it touches.
  • Reserve minimum-balance enforcement for the accounts that need it. Enforcing a minimum balance is a deliberate financial control, and the cost of it is that those users’ large jobs wait to be priced. That is usually an acceptable trade, but it should be a decision rather than a default.
  • Store held jobs on the PDServer for queues on machines that sleep. See How to store held print jobs on the PDServer. Early printing works on both storage locations, but server storage also removes the dependency on the capturing machine still being awake at release time.

Troubleshooting

A large job always waits for spooling to finish, at every printer. Check condition 1 first: the device almost certainly is not tracking its own jobs via a Print Director integration. Confirm on the device’s settings in Resource Manager.

One user’s jobs wait but another user’s do not, at the same printer. That points at condition 2 or 3, both of which are assessed per user. Check the rules assigned to that user and whether their billing account enforces a minimum balance. The Waiting column names which one.

The job released early but the printer still took a while to produce the first page. That is the printer interpreting the document, not Print Director holding the job. Compare against printing the same document directly to the device without Print Director in the path.

A release fails part way through a large job. The job is not lost. The reason appears against the job in the Waiting Jobs list, and the job data is retained so the release can be retried.

 

Document revision date: 2026/10/23
Software version: 2.5.15.3

How can jobs start printing even before spooling is complete