This will happen on a direct queue job if the "Zero Length Job" setting in Uniprint is not enabled. In a secure queue path, the phenomenon presents itself as "I sent the job from my workstation, but it's not there when I try to release."
First, some background: "zero byte" or "zero length" print jobs occur because the server size of the operation (the Uniprint server) is being told by the client side of the operation (the user's computer) that the job is, indeed, zero bytes long. This can happen for a couple of reasons:
- The Windows Spooler is using "0" as a place holder for the file size, but isn't updating it prior to sending.
- The print processor used by the client's print queue is not behaving.
- An interaction between the application and the printer driver is resulting in an empty file size.
- If using Pharos Popup, the job header arrived at the server in a malformed state.
Solving the first problem is not possible. Thankfully, that is a fairly uncommon problem. Here are some suggestions for the other issues:
- Don't use a third-party print processor. Windows provides a (usually) more than adequate print processor called WinPrint. To change, go to Properties > Advanced > Print Processor on the server's queue and change it to WinPrint. If you are using a Pharos package to deploy the queue, you will need to update the package. If you included the Updater module, your client base will eventually get the update. If you did not include the Updater, you will have to remove and reinstall the package.
- Change applications or printer drivers. I was using Adobe Acrobat Reader XI to test printing a customer's PDF file to a device. I kept getting the "zero byte" error. I shifted gears and used the Nitro PDF Reader instead, and the file printing just fine. I then changed the server queue to use a really old HP LaserJet driver (a 4000, I think) and then the job printed fine out of Acrobat Reader, too. Both queues were using the WinPrint processor. Again, if you change the printer driver for the queue, you will have to potentially redistribute your Pharos package.
- Modify the spool settings. By default, the Spool settings are configured to "Print after first page spools" because in the non-managed world you want the printer to start doing something right away. That can get in the way of a managed print environment, so try changing the Spool setting to "after last page spools."
- Turn off "Spool File Pooling." We have a really good article about that: Erratic print behavior, warnings of "deleted" jobs, excessive "spool" file sizes, inaccurate print attributes, incorrect user for print job, and 0 KB spool files .
I hope that this helps you out!