| Summary: | clist handling of fill adjust for clips is broken. | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Robin Watts <robin.watts> |
| Component: | General | Assignee: | Ray Johnston <ray.johnston> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | henry.stiles, sphinx.pinastri |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| Customer: | Word Size: | --- | |
| Attachments: |
vit6.pdf
images.tar.gz |
||
Created attachment 20410 [details]
images.tar.gz
The problem is reproduced in v.9.20 that displays wrong shapes, and in v.9.21 that shows extra jaggies in 'v'. All other versions work just fine. The v.9.21 was released in 2017-03-16, soon after the bug was filed.
Attached are cropped images produced by several Ghostscript version and my cropping script. I believe that this bug can be closed now.
|
Created attachment 13266 [details] vit6.pdf I have an example file that: 1) Plots a 'W' character. 2) Defines a clip region. 3) Fills the clip region with an image. If the clist is used (and it's a big file, so the clist is used more often than you'd hope), the clip region is drawn with fill adjust set to 0. If I nobble the file so that 1) doesn't happen, the clip region is drawn with fill adjust left at the default of 0.5. As far as I can see, there is no logic in the clist code to ensure that the correct value of fill_adjust is written before the clip region is defined. fill_adjust is set to 0 as part of step 1). It is never reset to 0.5. gs -dMaxBitmap=1000 -sDEVICE=png16m -o out.png -r300 -dSCANCONVERTERTYPE=2 vit6.pdf (The new scan converter currently shows this up with edges being more ragged than expected. I am looking into that. The problem with the fill adjust happens independently of scan converter used though.)