pstops mangles macintosh created postscript jobs #714

michaelrsweet opened this Issue May 11, 2004 · 1 comment


None yet
1 participant

michaelrsweet commented May 11, 2004

Version: 1.1.19 User: lists.joerhodes

"pstops" seems to have some issues when parsing Mac created postscript files. The output will cause foomatic-rip to fail, and thus no print job. If one takes the pstops filter out of the chain, and processes the ps file directly (and only) with foomatic-rip, it RIPs just fine and prints.

This is 100% reproduceable when using Adobe Illustrator (version 10) or Adobe Photoshop (version 7) on Mac OS 9 and Mac OS X. PS files are created using the foomatic ppd files from (since the destination printer is not a PS capable printer, and therefore has no native PPD). In this case, I'm printing to an HP 5 via foomatic-hpijs.

The PS files are recieved on the printing host (Redhat Fedora Core 1 on Intel) via netatalk (2.0) and PAP (papd simply pipes it's output to the lpr command). However, the same results are achieved if the PS file is transfered via other means and printing is attempted via the command line.

Quark print jobs sometimes suffer the same fate with embeded EPS files if "binary" encoding is used instead of "ASCII". However, this is not as reproduceable as the above.

I've uploaded a sample PS file generated by Adobe Illustrator that demonstrates this problem.



michaelrsweet commented May 13, 2004 User: mike

This was fixed in CUPS 1.1.20. Please upgrade and resubmit if you continue to have problems.

Also, it should be noted that the Adobe output does not conform to the Adobe Document Structuring Conventions, so if the output does get mangled, they need to fix it (the file reports itself as Clean7Bit,
which it clearly is not, and does not follow the requirements for embedding binary data in a document)

@michaelrsweet michaelrsweet added this to the Stable milestone Mar 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment