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* files. 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 wanted). Notes: - 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 for me. - 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 :) Sean
signature.asc
Description: This is a digitally signed message part
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba