Summary: | Lines at edge of glyphs with pswrite | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Ray Johnston <ray.johnston> |
Component: | Graphics Library | Assignee: | Henry Stiles <henry.stiles> |
Status: | RESOLVED LATER | ||
Severity: | major | CC: | christinedelight.top85, henry.stiles, leonardo, shailesh.mistry |
Priority: | P4 | ||
Version: | master | ||
Hardware: | All | ||
OS: | All | ||
Customer: | Word Size: | --- | |
Attachments: |
w.pdf
compr.ps compression program |
Description
Ray Johnston
2004-09-23 10:25:27 UTC
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 ;-) |