There are sometimes situations where printing of very large documents containing high resolution graphics, text and images is needed. With the growing technology of high end cameras flourishing in the market, image sizes are growing larger and larger. Additionally, image editing applications present endless opportunities to enhance and modify images to your heart's content. Due to the amount of information stored in images like this, the final spool job can sometimes reach multiple gigabytes in size. There are some issues seen when we print extremely large print jobs – our focus today will be on those issues, as well as some solutions. Let’s get started with having a look at the issues first.
To keep the scope of our discussion within reason, the environment in our example is Windows XP/ Windows Vista/Windows Server 2003 x64 clients and Windows Server 2003 or Windows Server 2008 x64 as the print server. To begin with, it is often thought that a print job cannot grow over 4 GB in size, but this is not true. The spool file (.spl file) which gets created can actually grow easily to over 4 GB in size. Thus, the obvious question, why do very large print jobs fail to print as expected? There are two reasons for this behavior:
The first aspect is when we are seeing the print job go to 3.99 GB and reset to zero and start over again. This behavior is just a benign issue of the display of the print job and has no actual effect on the actual printing of the Job. The issue with the UI showing the wrong size is known and does not impact the actual print job. The UI only displays 32-bit sizes and wraps larger values. Internally print job sizes are kept as 64-bit values.
The second issue is why the print job itself actually fails. First, it is essential to know which application is being used to generate the print job - is it a 32-bit application or 64-bit native application We normally see this issue when we have a 32-bit application printing to a 64-bit server. Here is what happens. When the application is printing, there are two ways the job may be programmatically created, as we can see in the diagram below (we also discussed several aspects of printing in our post on Basic Printing Architecture last year:
The Graphics Device Interface (GDI) enables applications to use graphics and formatted text on both the video display and the printer. Microsoft Windows based applications do not access the graphics hardware directly. Instead, the GDI interacts with device drivers on behalf of applications. The GDI can be used in all Windows-based applications. When a print job is created via the GDI interface, there is a limitation of 4 GB per page. If a single page is over 4 GB in size, it will not print properly. If a job is made up of multiple pages, but no single page is over 4 GB in size, you should not have a problem. So, what is the solution for printing large documents?
Winspool.drv is the client interface into the spooler. It exports the functions that make up the spooler's Win32 API, and provides RPC stubs for accessing the server. The OpenPrinter, StartDocPrinter, StartPagePrinter, WritePrinter, EndPagePrinter, and EndDocPrinters functions mentioned above are all provided by winspool.drv. The functions in winspool.drv are mainly RPC stubs to the local spooler service (Spoolsv.exe). By using these API's to create the job, the spooler will be able to bypass GDI and send the PDL directly to the printer via Winspool. Here is how a print job would be created with help of these API's:
And with that, we’ve reached the end of this post. Hopefully this information helps you understand some of the challenges involved with very large print jobs.
- Ashish Sangave
|Share this post :|
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.