Summary: | /undefined on composite EPS rendering | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Luca <lucaseverini> |
Component: | PS Interpreter | Assignee: | Ray Johnston <ray.johnston> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Customer: | Word Size: | --- | |
Attachments: |
The postscript file bad.eps that provokes the ps error
The postscript file good.eps that is rendered fine |
Description
Luca
2006-03-26 15:17:21 UTC
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 |