[THIN] Re: Hp Universal Driver
- From: "Joe Shonk" <joe.shonk@xxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Fri, 25 May 2007 08:40:31 -0700
Wow, yet another amazing masterpiece from Rick. Well done.
You would think that being the year 2007 and all that vendors would have
finally gotten things right. Printing has been around since beginning of
computers. Even before the first monitor and we today, don't have nearly
the issues with video cards and monitors as we do with printers.
Joe
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Rick Mack
Sent: Friday, May 25, 2007 5:53 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Hp Universal Driver
Hi Daniel,
That's actually not that easy to answer because it depends on the type of
printing and the intelligence of the application using the printer drivers.
Postscript ought to be more efficient for straight text documents with
simple graphics etc but that's most often not the case. For the bulk of
applications, PCL 6 is the more efficient of the protocols.
However, (sorry there's always one gotcha) past history has shown that the
PCL 6 drivers generally have more "features" and as a result are less stable
than PCL 4/5. I agree with you that postscript, with the exception of
printers using the Adobe drivers, used the Microsoft unidriver mechanism and
while not necesarily terribly efficient, was simple enough to be dead
stable.
Flame on.
Then HP lost the plot and started adding all sorts of enhancements to their
postscript drivers which has made some of their postscript drivers every bit
as bad as the worst PCL drivers. A good (or bad) example is the HP Color
Laserjet 4650 PS which can take the spooler out in no time at all.
Postscript is no longer an automatic safe choice unless you use native
Microsoft drivers. I also have to state that the HP Universal Postscript
driver isn't any better than th PCL driver so the size of the print job
(discussed below) should be the selection criterion.
Since I've gone this far I guess I may as well finish the rant and maybe add
some useful information.
HP obviously aren't the only player, they just have the present sorry
distinction of having some of the worst corporate printer drivers for
terminal services. Unfortunately, for people who have been playing with TS
for a long time, that sounds almost familiar :-(.
Xerox used to make the worst drivers under the sun, but now has some of the
best and the Fuji-Xerox driver development team are dead serious about
creating good drivers for terminal services. Konica Minolta high end printer
drivers are dead stable, but they are just incredibly inefficient. As an
real example, imagine printing a 5 page word document (2 MB) with embedded
pictures. Pause the queue before printing and have a look at the size of the
*.spl file under %systemroot%\system32\spool\printers. The stats I got were:
Konica Minolta postscript - 139 MB, Konica Minolta PCL - 45 MB, native HP
Color Laserjet 4500 - 8 MB. You just can't afford use Konica Minolta on a
WAN without a UPD.
Then there are Lexmark drivers with my pet hate, Lexdrvin.exe, that can
really slow down bulk logins, but that's just a good idea gone wrong. I
suppose someone thought it was a good idea to check all your printer driver
files (DLLs etc) on logon. That's why I use a group policy file security
setting to disable that sort of %!&^%!
Flame off.
If you don't have the luxury of using a real UPD (compression, no printer
drivers, eg PS4, ThinPrint etc, NOT HP UPD!) and/or have a mix of UPD and
network printers, there are a couple of things you should always do:
The first thing is to test the driver with Citrix' Addprinters or
StressPrinters utility to see if it kills anything. 80-90% of drivers will
pass, although some require a huge CPU overhead in just creating a printer
queue. I guess that still makes them bad in terms of logon printer creation
overhead, but at least they don't crash the spooler ;-)
If you want to test your existing production printer drivers, DON'T do the
testing on a live production system, at the very least it may require a
reboot. Either use a development server with no users on it, or backup a
production server using the Microsoft Print Migrator (PrintMig) and restore
on to a test machine where crashing the spooler etc won't matter. If you use
StressPrinters be aware that if you select a bunch of driers, it'll kick off
multiple instances of addprinters that will give you a lot more errors than
you'd ever see in a production environment. Test drivers one at a time, or
use a script wrapper to run AddPrinters against the drivers one at a time.
There were a couple of scripts posted about 4-5 months ago, one from me that
only worked on win2k3 and a more generic one by someone smarter than me that
worked on win2k as well.
Then try printing a standard document (one you use for all printer drivers)
and have a look at the size of the spooled print job. You'll see some
amazing differences in print job sizes, even among HP drivers. Go for the
driver that produces the smallest print job and that'll be as good as you
can get.
regards,
Rick
--
Ulrich Mack
Commander Australia
On 5/25/07, Daniel Sidler <daniel.sidler@xxxxxxxxxxxxx> wrote:
Rick,
Thanks for the info. Trying to tap into your experience here: when you say
that " HP UPDs are a big and ugly replacement for HP printer drivers that
are really really ugly", do you make any difference between PCL and PS
drivers?
In the past there was this kind of commonplace that PS drivers were more
stable than PCL, because they left out most of the fancy features the PCL
drivers sported. Would you second that?
Dan
Other related posts:
