Below is a recording of our Universal Print Drivers Webinar as well as answers to all of your wonderful questions during the event! The slide show (in PDF format) has also been attached.
Q: What kinds of things does the Print Processor add to the job?
A: The Print Processor's primary function is to convert to a document format (RAW, like PCL, PostScript, or ESC/P2 formats; EMF, when the client is sending to a print server in "optimized" mode; or Text). Beyond this, a Print Processor can also be engaged to support n-up printing, "electronic" collation (versus writing a copy of the print files 10 times to support 10 copies), watermarks, and other supported features like "private" or PIN printing, job storage (like the Canon imageRUNNER mailbox feature), and booklet (aka "imposition") making. -Scott
Q: So would the fact that the job is rendered at the client (workstation) side, explain why PDF's created using older versions of Adobe Acrobat tend to fail when printing via the latest version of Adobe Reader which has limited backwards compatibilty.?
A: Beginning with Acrobat 5 (supporting PDF version 1.4; for some reason, the Acrobat major version always supports a 1.x version that is one less), Adobe started to "pre-write" the print job spool file when the printer driver used was a PostScript language driver. This coincided, to some degree, with their earlier (much earlier) purchase of PageMaker from the failing Aldus Corporation and coincidental development of InDesign, as both graphic design products were essentially doing the same thing (which makes sense; who better else to write a PostScript file than the creators of that language!). However, this behavior didn't anticipate that many printer drivers are developed quickly and can do things "outside of spec" in terms of PostScript at the device, so when the two are mixed, you can get some bizarre things: missing page elements (a photo may be missing, or characters in words are gone), font transmogrification (Times New Roman >> Helvetica), odd scaling, missing pages, or print jobs that will not print. Adobe's stance is to use their "Print as Image" option in their Print dialog box's "Advanced" page, stating that the cause for the issue is a shoddy printer driver. Alternately, you can choose to standardize on a PDF viewer application that lets the Windows Printing subsystem do its intended job.
Comment by John after Scott's explanation: That makes sense. Our experience is that most of the jobs that fail using PDF format are Acrobat version 5.0 and earlier. They fail when using reader, however, they usually work when using the full version of Acrobat. Most probably because the complete editions can repair inconsistencies in PDF files during the open process, whereas the Reader product must take them "as is". -Scott
Q: Big issue: UPD often does not detect all the features of the printer, or does not detect the paper type and size properly, even for devices supported by UPD
A: Pharos Systems' advice is to not allow any automatic detection by the UPD at all, choosing to manually configure it for the best-effort options set for your devices. If a particular version of the UPD is being used and claims support for a specific printer model but is falling short, I would raise that with the manufacturer.
Q: Is there a multiverse print driver available?
A: I'm not familiar with the term "multiverse" when used in the printer driver context, but I am going to assume that you mean a manufacturer-agnostic driver. Unfortunately, as most manufacturers choose to eschew common language commands for various features in favor of their own internal command-set, a truly universal driver is a tough call. This is a primary reason that mixing manufacturers between printer driver and device is a dicey prospect.
Q: Can the 2-way communication be turned off? This type of communication has caused problems at times in large environments
A: If using the UPD outside of the Pharos solution construct, I would recommend that bidirectional communication only be enabled during the initial queue setup, and then disabled completely. If using it within the Pharos solution construct, I recommend that bidirectional communications never be enabled. By default they are, so it involves some quick work on the administrative end to get rid of it all.
Q: What kind of finishing options would be maintained/transferred to the actual device? Would some missing finishing options impede others (i.e. staple/punch but devide has only staple, does the job ignore punch and still staples ?
A: In my very unscientific testing, if a print job specifies options that do not exist on the target device then the option is simply ignored. By unscientifc, I mean that my test target printer is an HP LaserJet 4M with PostScript support, and it has absolutely no options at all. The only thing that has given me a fit historically is paper tray support. Think "PC load letter"
Q: Since error status would be available through SNMP, would the device in error (ex no toner/paper) be available or skipped as potential output device ?
A: Current versions of both Pharos Blueprint and Uniprint support "device status" monitoring as part of their release function, so if you retain this feature, a device with a problem that would prevent print would be flagged by us. The UPD in a Pharos scenario, remember, only connects to the Secure Release Service.
Q: Is this recorded ? I'd like to watch it again later.
A: Yep. -Scott
Q: Universal driver solves a lot of issues, but manufacturers (like HP) are frequently changing and updating their universal driver. What is the best way to upgrade/update to newer versions of the universal driver for Uniprint systems currently in service?
A: The recommended process is to first install the new driver version (paying attention to install the driver choice that contains the version number) on the server and then use the Pharos Administrator application to change it on your queues. Then, rebuild your packages. Hopefully, you're taking advantage of the Updater module, or you'll be forced into visiting your workstation fleet to manually update.
Q: Doesn't the UPD timeout and use a generic driver that typically works ? Aren't many of our customers using UPDs and happy, even though we don't allow the discovery ?
A: If, when installing the UPD to a queue object, a non-supported port (like FILE: or NUL) is referenced, it just chooses to not discover; it doesn't use a "generic" option.
Q: What is the solution to print jobs coming out in 'Sanskrit', 'Arabic', etc, as Scott mentioned?
A: Bizarre character output is normally the result of using an inappropriate printer driver (a Xerox driver for an HP device; a PCL-XL driver for a non-PCL-XL capable device). So just don't do that.
Q: Do we have a generally recommended language type for Pharos software (PCL5/PCL6/PS3) ?
A: Not really; printer languages are a bit like religion. Personally, I'm not a big fan of PCL-XL (aka PCL 6) in our mode because you run the risk of "unsupported" commands on print devices.
Q: For bi directional support, is that ports tab in phars admin, or in the o/s screen (devices & printers)?
A: The Ports tab option is only for those printer drivers that include a Job Monitor function (most do; you'll know if it does when the "Bidirectional Support" option is enabled). This option prevents "Error" status messages for the shared queue when turned off. The other options for bidirectional communications are normally found in "Configuration" or "Options" or "Advanced" configuration pages for the printer driver.
Q: Note: "Job Storage" is NOT 'redundant' in the Direct Printing configuration with MFP devices. Users may need extra security on some documents in a Direct Printing environment. User (of course) needs to know how to retrieve Stored Jobs.
A: Good point. Be careful with this option, however, as a device-supported function consumes hard disk space on the printer and can affect its performance/availability.
Q: That "bit.ly" URL on slide 18 seems to be going somewhere else.
A: Here are the compacted URLs again:
Q: Could Scott please comment on the Canon universal drivers when the recording is posted to the community site?
A: Canon does not have a "universal" driver, per se. Rather, they have a Generic PCL 6 driver. The important screenshot for this is found below:
You can define either a monochrome or color capable device supporting either A4 (the rough equivalent of Letter) or A3 (the rough equivalent of Tabloid, or 11x17) as a type of device. The "Get Device Status" button at the bottom uses the specified port as the transport to acquire things like paper tray and accessory configuration (which would not work in a Pharos configuration). Based on my limited testing, the print jobs coming from this driver page count correctly for page count, page size, copy count, color mode, and plex mode.
Q: What about the dell universal drivers?
A: Dell printers are typically rebranded Lexmark devices, but their Open Print Driver is somewhat different. When set up in "Static" mode, choosing a non-IP port will result in a driver configured for a Generic Laser Printer:
and the ability to configure some attachments/options. The current version available from Dell page counts correctly for paper size, plex mode (simplex or duplex), and color mode. It does not have an included Job Monitor (so no Bidirectional Support on the Ports tab), and seems to not have much in the way of bidirectional support unless attempting to specifically have it align with a specific network device. You can install a PCL 5, PCL 6, or PostScript driver using the Open Print Driver installer.
Q: What's your take on using Xerox UPD on non-Xerox devices (I have HP in mind)?
A: I'm hesitant to say "Yes" here simply because it turns into a "Pharos said..." discussion and in the end, it's just a bunch of hurt feelings. However, in the spirit of Community, I will say that general behaviors (duplex, paper size) carry through. Tray calls and other functions render unexpected results.