Bug 688618 - /undefined on composite EPS rendering
/undefined on composite EPS rendering
Product: Ghostscript
Classification: Unclassified
Component: PS Interpreter
PC Windows XP
: P4 normal
Assigned To: Ray Johnston
Bug traffic
Depends on:
  Show dependency treegraph
Reported: 2006-03-26 15:17 PST by Luca
Modified: 2008-12-19 08:31 PST (History)
0 users

See Also:
Word Size: ---

The postscript file bad.eps that provokes the ps error (24.67 MB, application/zip)
2006-03-26 15:36 PST, Luca
The postscript file good.eps that is rendered fine (24.67 MB, application/zip)
2006-03-26 15:51 PST, Luca

Note You need to log in before you can comment on or make changes to this bug.
Description Luca 2006-03-26 15:17:21 PST

During some testing, developing a quarkxtension to improve XPress4 EPS
separation, I've noticed this strange 'bug':
I have two DCS 2 EPS files generated by xpress 4 approximately 100MB in size
that are exactly the same except for 4 lines of ps comments in the header (the
comments are the ones used to specify the position and size of the cmyk color
Opening the file 'bad.eps' in gsview configured to use gs 8.53 provoke an
offending command:

Error: /undefined in ~
Operand stack:
   4   --nostringval--   --nostringval--   false   --nostringval--   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--  
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   false
  1   %stopped_push   1   3   %oparray_pop   1   3   %oparray_pop   1   3  
%oparray_pop   1   3   %oparray_pop   .runexec2   --nostringval--  
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--
Dictionary stack:
   --dict:1123/1686(ro)(G)--   --dict:0/20(G)--   --dict:77/200(L)--  
--dict:271/400(L)--   --dict:42/70(L)--   --dict:129/260(L)--
Current allocation mode is local
Last OS error: No such file or directory

--- Begin offending input ---
100467.66 -172124.32 tr
0 0 m
0 0 l
0 253.2814 221.7727 458.0056 496.0499 458.0056 c
496.0499 458.0056 l
769.3459 458.0056 991.1385 253.2814 991.1385 0 c
991.1385 0 l
991.1385 -252.951 769.3459 -458.0031 496.0499 -458.0031 c
496.0499 -458.0031 l
221.7727 -458.0031 0 -252.951 0 0 c
-100467.66 172124.32 tr
[0.33482335 0 0 0.33482335 0 0] um
%%BeginObject: image
[4.0178803 0 0 3.6830805 652.52469 1057.0006] um
12 11 8 [12 0 0 11 0 0] 4
%%BeginData:        479 Binary Bytes
--- End offending input ---
file offset = 94731264
gsapi_run_string_continue returns -101

If you open the other file 'good.eps' that differs from the other only for the 4
lines of comments in the header everithing is fine.
If you open the files using the gs console everything is fine therefore I think
 should be a bug related to gsview.
To shorten the files that are pretty big I deleted the 4 following plates; the
problem happens also without them.
Whatever I can do more for help you, let me know.

Best regards,

Luca Severini
Comment 1 Luca 2006-03-26 15:36:03 PST
Created attachment 2129 [details]
The postscript file bad.eps that provokes the ps error

File zipped.
Comment 2 Luca 2006-03-26 15:51:30 PST
Created attachment 2130 [details]
The postscript file good.eps that is rendered fine

Zipped file.
Comment 3 Alex Cherepanov 2006-03-26 16:53:39 PST
Reproduced in HEAD without GSview as:
gswin32c -dEPSCrop - <bad.eps
Comment 4 Raph Levien 2006-03-29 10:37:02 PST
Sounds like our pswrite used to generate files with a similar problem. See bug
#525044 for the explanation - it may be that one of the workarounds discussed in
that file might be workable for this issue.
Comment 5 Dan Coby 2006-03-29 10:57:35 PST
Try changing to min_left.
Comment 6 Luca 2006-03-29 13:14:21 PST
Hi everybody,

The explaination for bug #525044 makes sense to me and, perhaps, solve the
problem but, why if I change the header of the file deleting the comments about
cmyk plates without to change anything else the file prints well? Is such filter
procedure affected by the presence of some ps comments or, maybe, deleting the
comments move the inmage data to a nasty position/offset inside the file?
Please help me to understand.

Comment 7 Ray Johnston 2006-04-21 19:02:40 PDT
Change ASCII85Decode EOD handling to make sure that the EOD characters are
consumed before we provide the last bit of data to the caller. The ~> sequence
(actually could be <cr> <lf> ~ <cr> <lf> > ) left in the currentfile would
cause an /undefined error on the '~' or the '>'.

When the input is piped from %stdin the smaller buffers tripped over this
frequently with the test file simply because there were more buffer bounds

Note that this area is _still_ not quite the way Adobe works, but without
major surgery and analysis of Adobe filter behaviour we aren't likely to
achieve 100% compatiblity.

Since we handle the case where the EOD sequence is in the part of the buffer
that we defer processing on (if last is false) we should be quite similar
as far as when we process the EOD since if a complete EOD wasn't in the
buffer previously, the '~' was left there. Now we avoid returning the last
word of data if the complete EOD isn't in the tail of the buffer.

If the EOD sequence seen in the tail is preceded by the 'real' EOD before
the tail in the current buffer, the "false positive" does no harm. Similarly
if there is a malformed EOD '~' not followed by '>' (possibly with intervening
<cr><lf>) the error condition will still be detected when the '~' is actually
parsed in the deocder.

The patch is in: