[Samba] Print speed with an HP Laserjet 4

[Kurt Pfeifle]

Mike Brodbelt wrote:

> Kurt Pfeifle wrote:
> 
>>Mike Brodbelt wrote
> 
> 
>>>This printer is set up with the HP LaserJet 4 driver for Windows NT 4
>>>that came on the NT 4 installation CD. When the print job is redirected
>>>to a file, I get a PCL file that is 14830 bytes in size.
>>
>>So this is the result for the native Windows PCL driver.
>>
>>
>>>The networked LaserJet 4 printers were using a newer driver, downloaded
>>>from the HP website. This generates a PCL file that is 2392464 bytes in
>>>size for exactly the same document.
>>
>>I am not clear if this also was a native Windows driver? And if it
>>had some weird settings ("print as graphic" or similar)?
> 
> 
> Yes, this is also a native Windows driver, downloaded from the HP site.
> It provides a couple of different options from the one that shipped with
> NT, but nothing major. There is an "NT Forms" tab, andd a "Configure"
> tab that are driver provided. I've been through all the options, but
> can't see anything that explains the enormous bloat.

I guess it is either one of NT Forms or (if available) a "Watermark"
option. (If Watermark is selected it typicall renders the whole page(s)
to a bitmap which includes the watermarke and wraps the bitmap into
a PCL header/trailer and sends it away. This makes for long rendering
times on the host and large files, typically 1MB/page. Watermarks may
be even unwittingly used with an empty or [blank] string which causes
this behaviour.) Having said that, I don't know that particular driver
and may be completely wrong.

> Comparing the two PCL files directly, the small one contains PJL start
> and end codes, which encapsulate the text of the document and some PCL
> codes. The large file has PJL start and end codes (but somewhat
> different ones), and the rest is all binary.

As I said: it sems to be a bitmap.

> It's sent the data as
> graphics, or embedded the fonts, or something, but I can't see any user
> visible interface elements in the driver setup that might control this
> behaviour. The output has options for 300 and 600dpi (defaults to 600),
> and also for sending TrueType as bitmap (defaults to off), but I haven't
> yet tested combinations of settings.
> 
> 
>>>The new setup, uses the PostScript driver.

Which PostScript driver again? The Adobe one?

Also, what are the PostScript driver's settings in the PostScript options?
"Optimize for Speed"? That's a no-no --- rather use "Optimize for Portability"?

(Other PS drivers -- like the MS based ones -- use "Page Independence" [say YES]
to achieve the better portability.)

>>>Ghostscript is invoked to
>>>render this into PCL suitable for sending to the printer. I tested the
>>>PCL output by manually generating it:-
>>>
>>>cat pstest.prn | /usr/bin/gs -dSAFER -dPARANOIDSAFER -dBATCH -dNOPAUSE
>>>-q -sOutputFile=test_gs.pcl -sDEVICE=ljet4 -
>>
>>
>>So this looks like the ljet4 driver compiled into Ghostscript....
> 
> 
> Yes indeed.
> 
> 
>>>As I need to leave the billing system in place, I still need to use the
>>>PostScript drivers on the Samba server. The bottleneck appears to be the
>>>time to send the job across the network to the printer, and the time the
>>>printer itself takes to process the PCL it receives.
>>
>>
>>You are not mentioning the time it takes for Ghostscript to convert
>>the incoming PostScript to the PCL raster....
> 
> 
> Running the above command line on the machine doing the conversion, a
> bit less than 2 seconds.

OK.

>>Have you printed this "to file" and then sent it as "raw" to the printer?
>>(Oh, I seem to remember, that this was your initial experiment...)
> 
> 
> Yes, that's the 900k file. Faster than the 2Mb PCL file, though not as
> fast as the PCL driver from the NT CD.
> 
> 
>>>It would seem that
>>>the best way to optimise the printing process would be to reduce the
>>>size of the final PCL file. Is there any way of having ghostscript
>>>optimise the resultant PCL output for size?
>>
>>
>>It *may* help trying another driver.
>>
>>Which is the "driver" you are using on the Linux side of things? Still
>>ljet4?
> 
> 
> Yes.
> 
> 
>>What is the output of
>>
>>   head /etc/cups/ppd/[printername].ppd ?
>>
>>(This would show me which filter/driver you use.)
> 
> 
> Not using CUPS at the moment - the Linux side spooler is LPRng.

Sorry -- I forgot.

> I'm
> looking at CUPS with growing interest, and setting up a CUPS test
> install is on my list, but I have a working setup with LPRng, and don't
> have the time to change it at the moment. Printbill doesn't yet support
> CUPS, though that's starting to change. I suspect I'll switch over to
> CUPS in due course, but I think it's a few months away yet.
> 
> 
>>Also, have you checked for our latest recommendations of drivers
>>at Linuxprinting.org?
>>
>>    http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus
>>
>>(I can't remember what your printer models are. But there are more
>>than one driver to use with laserjets. You can choose between the native
>>CUPS builtin driver (used by laserjet.ppd, not listed on linuxprinting.org),
>>ljet4, hpijs, and gimpprint. ljet4 is recommended. Please test and tell
>>us if we should recommend another one.
> 
> 
>>From a preliminary look, the ljet4 driver generates the smallest file
> from my postscript, though this is still more than quadruple the size
> of the postscript file, and approximately 65 times the size of the PCL
> generated by the driver that originally shipped with Windows NT 4. To
> compare like with like I suppose I should test with Postscript generated
> by the Laserjet 4M driver that shipped with NT4. I'll do that in due
> course, and post results.

I know the gimp-print driver has options for very fast rendering (which
also makes smaller file sizes).  All drivers from Linuxprinting.org
can now be used with all spoolers. The newly released Foomatic-3.0 makes
all spoolers PostScript- and PPD-aware thru the "foomatic-rip" wrapper
script. Just check out the appropriate docu at:

   http://www.linuxprinting.org/foomatic.html
   http://www.linuxprinting.org/lpd-doc.html

If you use the "foomatic-configure" commandline, it will setup the
queue for your environment (spooler-specific, LPRng-specific), but
also stores everything in a spooler-agnostic (foomatic-internal) way,
so you can at any time completely migrate your environment of queues
and printers to another spooler (because foomatic-reconfigure just
generates again the cups-specific or what-have-you setup from its
spooler-agnostically saved files...)

> Thanks for the help so far,
> 
> Mike.
> 
> 

Cheers,
Kurt