Optimize HP UPD PCL5 Driver

Version 1
Visibility: Open to anyone

    Scott Olswold has this in the Universal Print Drivers Webinar Recording with Q&A and I thought it was worth of having its own home since so many use the HP UPD PCL5, especially with MobilePrint.

     

     

     

    For those using the Hewlett-Packard Universal Print Driver for PCL5, there is a great way to optimize the print file size generated by the driver. A colleague and I were trying to figure out why print jobs going through a secured queue were getting so large. And by large I mean waaaaay too much data in the file: an 8-page PDF that would "write out" to a PostScript file around 14MB turned into a 285MB print file through the UPD PCL5 driver.

     

    The fix is buried deep, deep in the configuration of the queue under Properties > Advanced > Printing Defaults > Paper/Quality as "Print Quality." If you install the UPD PCL5 driver and create a queue for it without pointing the Add Printer wizard to an actual HP LaserJet device (preferably a color LaserJet) it sets the "Print Quality" setting to 600 dpi (dots per inch; this is the native resolution of most laser printers). The alternate option for this setting is 300 dpi.

     

    Before I get to the juice, let's explore this "dpi" thing a little bit, since we are all -- admit or not -- the Subject Matter Experts for print. This is a little "beanie and propeller" moment.

     

    A graphic object like a JPEG, BMP, or GIF file is composed of pixels. A pixel is the smallest element that a device (monitor, printer, charged-couple device array -- anything that can capture our output an image) can manage. In image editing, we don't say that a picture is "300 dpi." Rather, we say that an image is 1800x1200 pixels, and we're going to squeeze those pixels into a print out that is 6"x4". Simple division tells us that the end image is going to be printed at a final resolution of 300 pixels per inch. A "dot" is a printer's term (an old one) that describes where the imager can put a spot of toner or ink. Back in the Golden Days of Desktop Publishing (a book I saw on a shelf in the new Steve Jobs flick) we started equating (ever so wrongly) "ppi" to "dpi" and it ended up perverting the lexicon of an entire industry.

     

    So how does that little tangent apply to this? A color image is composed of 3 primary elements: a Red, a Green, and a Blue byte value, all stacked within one pixel. These values tell your monitor how to display the color. We know that a byte is 8 bits, so a single color pixel is 24 bits. If we take a 6"x4" image and tell the printer driver to print it at 600 dots (pixels) per inch, we have (drum roll, while we put on our beanies) 24 x [(600x6) x (600x4)], or 207,360,000 bits of data (wrap it up: 24.7MB) to pass along in a print file!

     

    So we can quickly see that printing in color can end up being a very costly thing from a data size perspective.

     

    Back to the story...

     

    We really don't want 600 dpi to be our default value for Print Quality. Setting it to 300 dpi takes our file size (using the above example) to just a bit above 6MB -- better, but not perfect. So what, then?

    That's where pointing our UPD queue to a real, honest-to-goodness printer and allowing an automatic update fits in. If I point the queue to a Hewlett-Packard LaserJet CM6040, that setting inherets a value that wasn't there before:

     

    HP Quality Tab.jpg

    Yes! ImageREt 4800. ImageREt is an image-enhancement and optimization technology introduced by Hewlett-Packard within its LaserJet line. The "4800" isn't a measure of dots or pixels, and a higher number (the number after ImageREt) doesn't mean better. It just means "different on this model than on that one." But activating any ImageREt setting here decreases print file size significantly. That 285MB PDF? It became a 16MB file that ended up going to the printer.

     

    Benefits

    The benefits are numerous:

    • Improved spool time from the workstation to the Pharos server.
    • Faster handling during the "page counting" phase.
    • Less demand for disk space while awaiting release.
    • Faster spooling from the Pharos server to the printer.
    • Rapid job processing time on the printer.
    • Near, or "at speed" printing of the job.

    When you do this auto update, you will probably have to visit the "Device Settings" tab to ensure that trays, output choice, and finishing options are normalized to what the printers can actually do, but the extra little bit is well worth it. So How Do I Do It?On the server:

    1. Go into the Properties page of the queue.
    2. If needed, click the "Change Settings" button on the General tab.
    3. Go to the Ports tab.
    4. Add a port.
    5. Select Standard TCP/IP Port and choose "New Port...".
    6. Complete the Standard TCP/IP port wizard, using the IP address of your chosen LaserJet.
    7. Disable Printer Pooling and ensure that only the Standard TCP/IP Port you've added is chosen.
    8. Apply the change.
    9. Go to the Device Settings tab.
    10. Under the "Installable Options" group, click the configuration for "Automatic Configuration" (it will probably be Off) and change it to "Update Now".

    There will be a brief pause and then you may see the UPD's backend function split into view. Allow it to complete. When it is done, ensure that the option is set back to Off, change any options in this tab that you don't want (keep the device type to COLOR) and Apply it.

     

    If you go into the Advanced tab, click the Printing Defaults button look at the Print/Quality tab, you'll see your shiny new Image REt setting where the 600 dpi setting used to be. Now, resecure the queue. Here's where things get a little administratively-intense.

     

    For Uniprint

    You will need to update your package (if you're using packages) and hope that you enabled automatic updating. If you did, you're done: your clients will get the new setting right away and you're done. If you didn't, you'll have to get the old package off and put the new one in.

     

    If you're not using packages for your queue, you're in the same boat the Blueprint folks are in....

     

    For Blueprint

    You will need to disconnect all client instances of the queue and reconnect them. Sadly, the things you do in "Printing Defaults" won't automatically carry-over to anybody who's already connected to the shared queue. It's a user-level thing. I really wish it weren't so.

     

    If you have Group Policy, you can create a login script utilizing PrintUI.dll (lots of resources everywhere on it) to remove the queue and reinstall it. If you are using a software deployment utility, you can accomplish what a Group Policy would, but in the strength and beauty of a Visual Basic script...or CMD/BAT file if you prefer...using PrintUI.dll.

     

    Cheers,

    Scott