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
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
