Originally reported by: vojta@users.sourceforge.net Question: If you have a 64-byte file, and you read 64 bytes from it (having asked for only 64 bytes, not more), have you read the EOF mark? Some (authors of) PostScript interpreters say the answer is no, and I can see their point. This question comes up in the following situation. The pswrite device generates code which reads from currentfile by first using the ASCII85Decode filter, followed by the CCITTFaxDecode filter. By doing some experimenting around, I find that (with at least some embedded PS interpreters), the CCITTFaxDecode filter reads its input in 64-byte chunks. If the encoded data is an exact multiple of 64 bytes long, then the above situation occurs, and the ASCII85 end-of-file marker ("~>") is not read from currentfile. The interpreter then tries to execute that marker, resulting in: undefined; offendingcommand = '~' This occurs, for example, on the HP LaserJet 8150 DN printer. I can think of a number of possible ways to fix this problem. One way would be to retain a copy of currentfile after applying the ASCII85Decode filter but before applying the CCITTFaxDecode filter, and then doing a dummy read from that file in order to be sure to hit the EOF. But a simpler way would be to add the following to the pswrite prologue, so that "~" is now defined, and that "~>" has no effect when executed: /~{currentfile read {pop} if}! Here's a snippet from a file produced by pswrite that makes our printer choke: , 1095 5468 42 50 /7I $C 25q]L+O>lM4%+.9"<3iW6,&P2-9=r#YG_>Kl2Ue`qcj*ShqHghBX.9ZlnFc6_(N]G_Vp3hs8W,u 8VpZe~> , If you remove the "~>" in the fourth line, then the file prints correctly. (I am not suggesting that pswrite should ever omit the EOD marker when writing ASCII85-encoded data; I merely mention the above to confirm that the phenomenon discussed above is really happening.) One more thing: I believe that this problem is unrelated to the setting of the EndOfBlock flag in the CCITT filter parameter dictionary. This particular problem is occurring with EOD markers at a different stage in the processing.
Comment originally by alexcher@users.sourceforge.net Logged In: YES user_id=65750 IMHO the best fix for this problem is to limit the source stream with 0 (%%EndBinary) /SubFileDecode filter instead of ASCII85 EOF marker. This string cannot happen in ASCII85 stream by chance. It does nothing when interpreted and contributes to DSC conformance.
Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 Dear Paul Vojta, Please send the file, which fails with "undefined; offendingcommand = '~'" on the HP LaserJet 8150 DN printer, to igor@artifex.com , or attach it to the bug report. Thank you.
Comment originally by vojta@users.sourceforge.net Logged In: YES user_id=197485 OK, I've attached a sample file to the bug report. It was produced by converting a text file first to ps (via a2ps), then to pdf via ps2pdf, then back to ps via pdf2ps. For this file, line 548 trips up the interpreter; deleting the ASCII85 EOD marker from that line gives you a file that will print correctly.
Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 The patch http://www.ghostscript.com/pipermail/gs-code-review/2002- March/002150.html has been committed.