At some sizes and rotations, some glyphs have a line at the edge of the character. This was seen by a user and reported by Stefan Kemper as a bug against the examples/waterfal.ps at 600 dpi. To verify the problem, I created a subset that shows the problem at a couple of sizes. run the following PostScript with: gs -sDEVICE=pswrite -sOutputFile=w.ps << /HWResolution [ 600 600 ] /PageSize [ 15 20] >> setpagedevice 15 0 translate 90 rotate 2 2 moveto [ 9 12 ] { /Helvetica findfont exch scalefont setfont (D) show } forall showpage quit View the resulting w.ps at 600 dpi using: gs -r600 w.ps I set the priority at P2 since we have a couple of customers that routinely use the pswrite device, and that use landscape rotations.
Created attachment 917 [details] w.pdf Distilled w.ps with Adobe Distiller 6 and viewed the result with Adobe Viewer. It doesn't paint the line. So the problem happens in the image rasterization step, right ? Or maybe GS has in unconforming behavior when image has insufficient data.
I examined the output from the filters (ASCII85Decode piped to CCITTFaxDecode) and determined that there are only 42 lines worth of data being generated for a 43 line image. Similarly for the second 'D' at 12 points. Since this appears to be a problem with the filters used to create the data (CCITTFaxEncode piped to ASCII85Encode) I will continue the analysis and find the problem. Examining the gdevps (pswrite) device, the correct amount of image data is being generated and passed to the filters via psw_put_image_bits.
BTW, maybe we observe another bug when rasterize w.ps. As I recall PLRM, if an image has insufficient data, the missed lines must left unpainted. So the black line isn't conforming.
The error happens at decompression, not compression. The following program generates 1140 bytes of data on Ghostscript instead of 1160. %! /f1 (decompr.txt)(w) file def <~4pQrEs!"Rps8W-!s8W-!s8VJ7lYHOT95FE=D/:nk['7F"@4MNg=Ugh#'l"RdTnNn'0Ml/Q<&"~> << /K -1 /Columns 80 /Rows 58 /EndOfBlock false /BlackIs1 true >> /CCITTFaxDecode filter 1000 string readstring pop f1 exch writehexstring f1 closefile The black line in the image happens because the stream is converted to the string in the prologue, generated by pswrite device. Since the string it is not long enough, it is reused by the image operator showing the vertical stem in D twice.
Created attachment 2219 [details] compr.ps compression program My previous comment didn't explain why I believe that the error happens during decompression. The file attached generates a compressed stream from the raster data. The compressed data are identical on GS ant other interpreters. Distiller correctly decompresses this stream but Ghostscript doesn't.
I ran the test PS from comment #0 against the latest revision (r8180) and found that the problem did not appear. I have narrowed it down to finding that in r7525 the problem still appeared and disappeared starting with r7526. Since r7526 had to do with changes to character bounding box handling, it may be that instead of fixing this bug, r7526 just changed the generated (w.ps) PostScript in such a way as to mask it. So, I'm not sure if this bug was fixed by r7526 or not?? I'm adding leonardo to the cc list so that he may take a look at this and give his opinion about this question.
I'm not a pswrite expert. I believe we replaced pswrite with ps2write.
Tried with r9931. The program Alex provided in #4 still generates only 1140 bytes (56 lines, 2 lines missing). So the problem is still there. Reproduced on MacBook Pro 13" + Mac OS X 10.5.7 + Xcode 3.1.2.
This is a problem CCITTFaxDecode
Bug still reproducible in Ghostscript 9.03
Henry says (comment #9) that this is a CCITTFaxDecode problem so I'm assigning it to him as the owner. We no longer support pswrite at all, so this may be academic now.
Resolving to "LATER" because "MUCH LATER" wasn't an option ;-)