Hello, 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 plates). 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 --- ~> %%EndData gr gr gs 100467.66 -172124.32 tr n 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 cl -100467.66 172124.32 tr eoclip gs [0.33482335 0 0 0.33482335 0 0] um %%BeginObject: image rovp [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 DALiM_jpegimage s4IA>!"M;*Ddm8XA,lT0!!*&R!(-_l"pP;:"UG><#71\B$4IUX$k!FO)%mSn'HJ)6*ZZ.=*$?LZ-Qj Ta,9.[O2^p:30f1^D+"''33&3TK1Ggle^]5&S!"/c8"@Eb$9b@A.&HGH9!<9t;*rl9A"T\W)!<E3$z !!!!"!WrQ/"pYD?$4HmP!4<@<!W`B*!X&T/"U"r.!!.KK!WrE*&Hrdj0gQ!W;.0\RE>10ZOeE%*6F" ?A;UOtZ1LbBV#mqFa(`=5<-7:2j.Ps"@2`NfY6UX@47n?3D;cHat='/U/@q9._B4u!oF*)PJGBeCZK 7nr5LPUeEP*;,qQC!u,R\HRQV5C/hWN*81['d?O\@K2f_o0O6a2lBFdaQ^rf%8R-g>V&OjQ5OekiqC &o(2MHp@n@XqZ#7L%Ko-!9`S;r9)nrV!:Ym99$)OIjRc>L#H\\<R[s:P73t3Fd9lq,~> %%EndData gr gr gs 100965.03 --- 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
Created attachment 2129 [details] The postscript file bad.eps that provokes the ps error File zipped.
Created attachment 2130 [details] The postscript file good.eps that is rendered fine Zipped file.
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.
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. Thanks. Luca
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 conditions. 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: http://ghostscript.com/pipermail/gs-cvs/2006-April/006475.html