We recently upgraded to Pharos 9.0R2 and at the same time, started using the HP Universal Printing PCL6 (v6.5.0) driver for all of our HPM608 printers. We have encountered a random issue with PDF documents printing parts of the text upside down (mirror image). Not the whole document but paragraphs in the middle of a page but the rest of the page prints correct. And some pages are all correct. It is not all the time and I can take a PDF document that printed wrong and print is 5-10 more times and cannot duplicate the issue. We also encountered a JPG file that printed completely mirror image and I as able to duplicate it once but not since then. One other thing to note is that we were using the "winprint" print processor with our previous version of Pharos and we are now using the default hpcpp210 process on our queues. Could that be the issue? Has anyone every encountered this?

I trust nobody'sprint processor, not even Microsoft's, but the in-built "WinPrint" processor won't cause you as much grief, and if you ever need to escalate anything to Microsoft, you will at least be in a "supportable" configuration.

Print processors can definitely make problems with text pop up, because one of their tasks is font handling (remember: in Windows Vista (and higher) and Windows 2008 (and higher), client side rendering is the default, so the client is creating the PostScript or PCL code, not the server) during conversion to the printer language from the EMF file. And if you are deploying queues via Pharos Popup, the clients are doing all the heavy lifting, too. And if there were an application/file format ripe for goofiness, it will be PDF since the file format can cause text to be handled simultaneously as a text object or a graphic object depending on:

its "layer" order

any transparency applied to an object or objects

Opting to run with WinPrint as your queue's print processor drags along some potentially unkind things, depending on your users, because some drivers will require their 3rd party processor for some print options to work (like booklet printing, duplex mode, n-up, watermarks, etc.) or even list as available, so test the stuffing out of it. If your user population is largely the "I just need toner on paper so this assignment isn't late" variety, they may never see the difference. But there will always be a few who mention something not working for them.

Thanks Lisa. That’s good to know because I might be in the same boat too soon. I wonder what’s the best way to contact the correct HP development team to report issues or feedback? Anybody have any suggestions?

Seems to me that all the PCL HP Universal Print Drivers drivers have various issues, although the flipped/mirrored documents associated with recent version(s) were most pervasive. Other other versions have PCL XL errors when printing PDF's. I believe PostScript works best for us.

That's because the Universal Print Driver is being used for a purpose for which it was never intended. When it was first introduced, and through to this day, it was positioned as a "single driver" solution for HP fleets. The problem is that the lexicon that permeates through both IT and this industry equates the word "driver" with "queue" and that is just not true. You install a printer driver on a computer system. The purpose of the driver is to maintain all of the code needed to properly interact with the peripheral device (IT 101 for many of you, I know, but it helps in the understanding). When it comes to printing, the printer driver is used in the creation of the print queue object, which completely describes the single, discrete physical entity at the end of your (Ethernet, USB, parallel, COM) cable. The print queue object is a complex of the printer driver, a communications path, and a specific configuration--supported by the driver--for the destination printer.

Prior to the UPD, if you had 10 different printer models, you had 10 different printer drivers and the administration was a chore. The Universal Printer Driver allowed a single driver instance to maintain across as many queues as you needed to create for the various devices in your environment, and they enabled (via communications across its path) that queue to self-configure. THAT is its value proposition, nothing more. We (all of the guilty parties involved) have bent its original purpose and value statement to meet our own means, and with that bend comes a degree of risk. PCL, oddly enough, notably more so PCL 6/PCL XL, is a more frequent victim to this risk because the PCL language is more device-specific in how it writes itself out through the printer driver than is PostScript. That is why PostScript is often an add-on ($$) option with a printer. It is more portable a language, and it also requires (in most cases) more memory on the printer to raster into the 0s and 1s that make the laser happy.

I've had to re-evaluate drivers for my Xerox printers as I've had goofy printing since the beginning of the year, so it's not just the HP printers that are having issues. I had to assemble my list of available drivers and start testing them one at a time until I found the correct ones that worked for me. I settled on the GPD PCL6 v3.3.347 as my "go to" driver for now.

Just curious, but why did you not choose the Xerox Pull Print driver? Xerox maintains this with the same parity as the GPD, but it has the glorious distinction of not requiring a printer connection to function well. It comes in both PostScript and PCL flavors, and can be modified with the same distribution XML as the GPD can.