Printer UnPICTifier - 1.0Fixes a problem w/non-OS X IPP print servers |
|
||||||||||||||||
|
|||||||||||||||||
Feedback Summary:
| This Version: | |||||
| Overall Rating: | Not rated (0.0) | Features: | Not rated (0.0) | Support: | Not rated (0.0) |
| Ease of Use: | Not rated (0.0) | Quality / Stability: | Not rated (0.0) | Price: | Not rated (0.0) |
Key to Types of Feedback:
Reviews
Troubleshooting
Usage Tips
Developer Notes
Commentary
Featured Reviews
I didn't find an option to use ASCII for sending... - Version: 1.0, 6/19/2003 06:28PM PST
TripleF3000
however, using "Save As" PostScript and dropping the file onto the printer in Print Center worked. This is under Acrobat full version, don't know if the Reader can save as PostScript as well.
The easiest thing… - Version: 1.0, 4/14/2003 06:39AM PST
nbfa
to do is to send your job via ascii instead of binary. It's fat, but it works. The CUPS-supplied pictwpstops filter expects the Document Control Structuring (DCS) declaration to indicate where ascii ends and binary begins, but most apps, including Adobe's (who created the DCS standard) don't follow it. The filter will then just process the whole binary output as binary PS, which is rather malformed. Deliver it via IPP (or even lpr) to another non-MOSX print server running an original CUPS 1.1.18 distro and it will run the pstops filter, but junk in = junk out. The PS printer will then not know whether to use BCP or TBCP to process the incoming, malformed PS. I haven't tried this, but it's intriguing. CUPS 1.1.19 should have new filters for this situation, I hear.