For the case of an Imagemask (in fact any imaging operator), the interpreter should reuse the string as needed to satisfy the imaging operation. ( see page 291 of PLRM). The attached example contains only 2 bytes of data, but the imaging operation is expecting much more. For the attached example, the stream passes on the EOFC to the simscale.c filter (when you have -dDOINTERPOLATE). With a fix for bug 689888, this causes the filter to pass the EOFC on, which will make the ImageMask not to appear. A solution would be to wrap the sting data into a procedure when dealing with imaging operators, since the data should be repeatedly read. For the attached example, /DataSource <00FF> becomes /DataSource { <00FF> }. Thanks to Ray for stepping me through this.
Please attach the sample file.
Created attachment 4089 [details] imagemask-with-pattern.ps In the file, changing /DataSource <00FF> to /DataSource {<00FF>} solves the issue. Sorry I forgot to attached it earlier.
The image interpolation in the source color space can not be properly tested until this but is fixed.
Since this bug is blocking 689246 (a P2 level bug), I am bumping this up to the same priority.
Wrap string data source into a procedure when /ImscaleDecode filter is installed, to ensure repeated reading of the string when the imagemask needs more data than has the string. The following patch is committed as a rev. 8854. http://ghostscript.com/pipermail/gs-cvs/2008-July/008435.html Regression testing shows no differences.