Bugzilla – Bug 688618
/undefined on composite EPS rendering
Last modified: 2008-12-19 08:31:56 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
Error: /undefined in ~
4 --nostringval-- --nostringval-- false --nostringval-- --nostringval--
%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--
--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
[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.
Created attachment 2129 [details]
The postscript file bad.eps that provokes the ps error
Created attachment 2130 [details]
The postscript file good.eps that is rendered fine
Reproduced in HEAD without GSview as:
gswin32c -dEPSCrop - <bad.eps
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.
Try changing to min_left.
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.
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: