The problem is not Apple's fault. It is not the CUPS people's fault, either. It mainly lies with the application developers of Carbon CFM programs. Here's the short answer:
CUPS 1.1.18 process jobs using filters; when the pictwpstops filter recieves a job, it looks for a Document Structuring Convention (DSC) -- a standard established by Adobe. Adobe themselves do not use that standard on all their applications. That declaration will spell out in the outputted PS what part is in binary and what part is in ascii. The developers at CUPS state that if a program does not follow this convention, their filter will process the job as binary, entirely, and without regard to two other protocols (which I'll describe next.
PS printers receive binary jobs and process them using either BCP or TBCP (or neither). That decision on what protocol to use varies from printer to printer, it even varies on why type of interface the job is received or, I believe, what protocol is used to send the job (PAP versus IPP). Even whether the job is vector-based or raster will change the way the printer chews up the binary.
When your PS printer gets the job, it's getting malformed PS. The simple way around this is to tell your application to send the job NOT as binary (since it likely isn't following the DSC specification). Should the app produce ascii PostScript, the CUPS filters, including the pictwpstops filter (that's essentially Mac OS-specific due to Mac OS 8/9's dependance on PICT for QuickDraw display) will ALWAYS output ascii PS and your printer will be happy.
Your Linux CUPS queue is getting malformed, binary PS and running the pstops filter on it -- but it's still processing junk. Junk in, junk out.
Other than outputting your jobs via ascii from your programs' printing sheet, you should be yelling at the manufactures of various applications for not following the DSC specification. Meanwhile, the CUPS people say that with 1.1.19, the filters will be binary, BCP and TBCP aware; likely, that will mean it will "know" about your printer (perhaps via the PPD, which includes the capabilities of the printer) and output accordingly.
Alternatively, use only Cocoa applications to print; they use Core Graphics PDF to PS (cgpdftops) filter.
Slashdot Mirror
Likely, they've added pipelining.
The problem is not Apple's fault. It is not the CUPS people's fault, either. It mainly lies with the application developers of Carbon CFM programs. Here's the short answer:
CUPS 1.1.18 process jobs using filters; when the pictwpstops filter recieves a job, it looks for a Document Structuring Convention (DSC) -- a standard established by Adobe. Adobe themselves do not use that standard on all their applications. That declaration will spell out in the outputted PS what part is in binary and what part is in ascii. The developers at CUPS state that if a program does not follow this convention, their filter will process the job as binary, entirely, and without regard to two other protocols (which I'll describe next.
PS printers receive binary jobs and process them using either BCP or TBCP (or neither). That decision on what protocol to use varies from printer to printer, it even varies on why type of interface the job is received or, I believe, what protocol is used to send the job (PAP versus IPP). Even whether the job is vector-based or raster will change the way the printer chews up the binary.
When your PS printer gets the job, it's getting malformed PS. The simple way around this is to tell your application to send the job NOT as binary (since it likely isn't following the DSC specification). Should the app produce ascii PostScript, the CUPS filters, including the pictwpstops filter (that's essentially Mac OS-specific due to Mac OS 8/9's dependance on PICT for QuickDraw display) will ALWAYS output ascii PS and your printer will be happy.
Your Linux CUPS queue is getting malformed, binary PS and running the pstops filter on it -- but it's still processing junk. Junk in, junk out.
Other than outputting your jobs via ascii from your programs' printing sheet, you should be yelling at the manufactures of various applications for not following the DSC specification. Meanwhile, the CUPS people say that with 1.1.19, the filters will be binary, BCP and TBCP aware; likely, that will mean it will "know" about your printer (perhaps via the PPD, which includes the capabilities of the printer) and output accordingly.
Alternatively, use only Cocoa applications to print; they use Core Graphics PDF to PS (cgpdftops) filter.