[Samba] Re: CUPS Print Quality -- WAS -- UPDATE Where are the ADOBE PS Drivers?

[Sean E. Millichamp]

On Thu, 2004-09-09 at 09:05, Chris McKeever wrote:

> Sean - it sounds like you finally got the CUPS processing print jobs
> working using the vendor specific PPD's... Have you noticed any
> quality issue with the resulting print job?  The reason I ask, is I
> got an HP4 working with the CUPS processing the job.  The quality of
> the output is noticeably poor compared to the actual windows driver
> printing RAW through CUPS (it looks almost like the output was created
> into a picture and then printed).  Now, I am using the built in CUPS
> 'HP LaserJet Series' PPD - so that may be the difference (vendor verse
> non-vendor PPD)

Probably the big difference here is that it sounds like you are sending
to non-Postscript capable printers.  If you use the Adobe (or whoever)
Postscript drivers on Windows as is recommended for maximum CUPS
integration and support then if your printer doesn't speak Postscript
you'll have to chug it through ghostscript into whatever language your
printer is expecting.

I would guess that there is probably at least some quality lost during
that conversion and the resulting output would depend entirely on
ghostscript's ability to translate (render) the Postscript generated by
the driver on Windows into your printer's native tongue.

If you didn't need to do the PS->(some other language) conversion on the
CUPS server then I suspect you would see better resulting output. 
Trying to avoid this PS->(other) conversion step is one of the reasons
why I generally only support PS capable printers.  You might want to
look into adding Postscript support to your printers if it is available
as an add-on option (assuming you don't want to continue to just use
CUPS in raw mode - there really isn't anything "wrong" with that, it's
just not how I'd like to have my system setup).

> Can I just clarify that you are using the cupsaddsmb from 1.1.21rc2
> but using cups 1.1.20 - and the reason is for its PPD processing to
> clean up potential 'bad' postscript generated by the vendor PPD

Actually, I'm using a derivative of CUPS 1.1.17 as it is in Red Hat
Enterprise Linux 3.  But yes, I am using cupsaddsmb from 1.1.21rc2 with
a one-line code modification (which I believe I posted earlier) to let
it compile within the 1.1.17 source tree so I can have it modify out any
PPD irregularities and install the Windows 2000/Adobe based PS drivers.

To be clear:  The extent of the 'bad' postscript it cleans up is nothing
to do with the actual Postscript generated by the Adobe driver.  It is
merely to ensure that the PPD doesn't instruct the driver to prefix the
Postscript output with printer-specific directives.  If CUPS doesn't see
a properly formatted Postscript header it doesn't treat it as
Postscript.  The actual Postscript generated by the Adobe driver is left
as-is.

My recommendation, if the output when using the Postscript driver isn't
acceptable quality-wise then try either:
1) A different ghostscript filter (maybe something else will convert it
better into your printers native tongue)
2) Continue to use the native vendor driver in CUPS raw support mode if
you don't need CUPS page accounting, etc.
3) Obtain either a printer that speaks Postscript or obtain an upgrade
for your existing printer to allow it to speak Postscript.  Then use the
PPD supplied by the manufacturer with it and no conversion will have to
be done.

#3 (Postscript entirely throughout, no conversion) is the ideal
configuration from a CUPS design standpoint but really... go with what
works best for you.  If raw mode works and you don't have a problem with
it then I'd stick with it.  Just next time you go printer shopping look
for Postscript support.  You might pay a little extra but I find it
worth it.

Best,
Sean

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba/attachments/20040909/1e91eb50/attachment.bin