Bug 697458 - clist handling of fill adjust for clips is broken.
Summary: clist handling of fill adjust for clips is broken.
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: master
Hardware: PC Windows NT
: P4 normal
Assignee: Ray Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-30 09:14 UTC by Robin Watts
Modified: 2021-01-02 02:53 UTC (History)
2 users (show)

See Also:
Customer:
Word Size: ---


Attachments
vit6.pdf (21.38 KB, application/pdf)
2016-12-30 09:14 UTC, Robin Watts
Details
images.tar.gz (23.99 KB, application/gzip)
2020-12-29 19:34 UTC, Peter Cherepanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Watts 2016-12-30 09:14:02 UTC
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.)
Comment 1 Peter Cherepanov 2020-12-29 19:34:42 UTC
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.