[gs-bugs] [Bug 692321] New: incorrect rendering to ijs device

[bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=692321

           Summary: incorrect rendering to ijs device
           Product: Ghostscript
           Version: 9.00
          Platform: PC
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P4
         Component: Other Driver
        AssignedTo: support at artifex.com
        ReportedBy: rschmidt at frii.net
         QAContact: gs-bugs at ghostscript.com


Created an attachment (id=7639)
 --> (http://bugs.ghostscript.com/attachment.cgi?id=7639)
postscript (from OpenOffice) that is rendered incorrectly.

On Slackware-13.37 a pure text (no graphics) postscript file renders (using the
ijs device) by compositing(with an OR operator) the text into a buffer
containing previously rendered text. This begins after the first page of
rendered output and continues for the remainder of the document. The buffer is
about 13/16" long on the paper - about 240 raster lines at 300dpi. More and
more 1 bits pile up until the segment is completely black, but the presence of
the old data is clearly visible before too much piles up. The .bmp debugging
output from hplip/prnt/hpcups , which directly captures the data passed thru
the pipe by the ijs client, also contains the erroneous composited data. 

The rendered output is normal on the screen if produced by "gs foo.ps"
The printed version is generated via "lpr foo.ps" with CUPS installed.
Reverting to ghostscript-8.71 "fixes" the problem. 

I attach "foo.ps", which is small. The .bmp files are available on request, but
are 90MB per page!

LinuxQuestions.org has a thread will several posts about this problem...

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.