Bug 525044 - pswrite incompatible with some RIPs
Summary: pswrite incompatible with some RIPs
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PS Writer (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Igor Melichev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-03-02 21:56 UTC by Jack Moffitt
Modified: 2007-12-13 12:55 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Moffitt 2002-03-02 21:56:45 UTC
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 1 Alex Cherepanov 2002-03-03 13:03:02 UTC
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 2 Igor Melichev 2002-03-11 10:49:17 UTC
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 3 Jack Moffitt 2002-03-11 19:21:22 UTC
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 4 Igor Melichev 2002-03-13 08:05:43 UTC
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.
Comment 5 Igor Melichev 2002-03-13 08:05:45 UTC
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.