| Summary: | incorrect rendering to ijs device | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Rod Schmidt <rschmidt> |
| Component: | Other Driver | Assignee: | Default assignee <ghostpdl-bugs> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | chris.liddell |
| Priority: | P4 | ||
| Version: | 9.00 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: | postscript (from OpenOffice) that is rendered incorrectly. | ||
We're unlikely to look into this unless you can supply a Ghostscript invocation to reproduce the problem - ""lpr foo.ps" with CUPS installed" doesn't help us to reproduce the issue in a debug environment. This bug has been fixed in 9.02 which wasn't yet available on Slackware when the bug was reported. Thanks for the fix... Thanks for confirming it. |
Created attachment 7639 [details] 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...