[Samba] Re: UPDATE Where are the ADOBE PS Drivers?
sean at compu-aid.net
Thu Sep 9 12:29:52 GMT 2004
On Wed, 2004-09-08 at 20:49, Michael Lueck wrote:
> Sean E. Millichamp wrote:
> > The new cupsaddsmb apparently is designed to
> > modify these "bad" PPDs during the installation so they generate
> > Postscript output that is acceptable to CUPS.
> So what you are saying is that if the vendor has "bad" PPD files, and
> you upload them via the APW method, then it will not print correctly?
I've never used the APW method with the Adobe/Windows PS driver and
vendor supplied PPDs so I can't comment on that scenario.
What I meant was that some vendor PPDs generate otherwise valid
PostScript with some printer specific directives at the beginning (on my
HP LaserJets those tend to be of the form "@PJL .....") when processed
by the Adobe PS drivers on Windows. So then Windows sends that PS
output to Samba, which then passes it off to CUPS, which then tries to
identify the format of the data using rules in the /etc/cups/mime*
When the file starts with a non-standard Postscript header (like @PJL)
it doesn't match the 'application/postscript' mime type and (I believe)
falls back to 'text/plain'. So CUPS ends up sending what otherwise
would be valid Postscript to the printer out as just a text file so you
get reams of Postscript code instead of the expected output.
The cupsaddsmb in CUPS 1.1.21rc2 seems to do some processing on the
vendor supplied PPD before installing it in the Samba [print$] share so
that those special codes aren't generated and it starts as valid
Postscript so CUPS types it properly (and you get the output you
- The CUPS Driver for Windows talked about in the Samba How-To won't
send those invalid job prefixes even though the PPD might specify it.
However, there are some fundamental bugs with the CUPS Drivers for
Windows 5.x series that is forcing me to switch to the Windows 2000
Postscript driver (based on the Adobe ones). Most of the printers I
deal with are HP with PS support and the PPDs almost all generate the
invalid @PJL commands before the regular PS so this is a serious problem
- If your vendor's PPD files didn't generate any non-conforming
directives at the beginning of the Postscript you would never notice
this as a problem.
- The CUPS raw mode would probably work fine for any of these "bad" PPDs
but then you would lose the advantages gained by sending CUPS
Postscript. You would lost page/job accounting and (though I'm far from
a CUPS expert) I believe you lose most/all of the powerful CUPS
filtering pipeline. None of which I've ever used but I could see where
some organizations might want access to it....
> Maybe I know why I use Samba / CUPS for raw spooling and use the
> vendor print drivers (HP PCL6 for example)....
I used vendor drivers in the pre-CUPS Red Hat Linux 7.1 days with very
early Samba 2.2 releases and the Add Printer Wizard. At that point the
Samba NT printing support was brand new and still buggy and combined
with some buggy vendor print drivers I got burned very badly with the
whole setup. Had hundreds of users down for hours while I rebuilt the
Samba printing setup from ground up, etc. So it was probably due to
that experience but I still see that as my last resort option. Besides,
there are situations where page accounting would be required so I like
to leave my options open. But many times in the last week until I got
this tackled I thought to myself I should just go the vendor drivers +
raw route. I'm sure it's not as bad as I remember :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba/attachments/20040909/a58667ba/attachment.bin
More information about the samba