Starting with r9852 some of the nightly regression files have differences that our users might find objectionable. For example, in the file comparefiles/pdftops.pdf the phrase"Not reporting error to user" near the middle of the screen is underlined with r9851 and with Acrobat Pro 9 but not with r9852 when rendered at 72 dpi (see attached files). The command line I'm using: bin/gs -sDEVICE=tiffg4 -r72 -o test.tif ./pdftops.pdf Other files that have similar differences include: test-hyperref.pdf vtm2k.pdf annots.pdf smdf.90441.102.pdf 031-01.ps PT.ps Bug690269.ps 136-01.ps 281-01.ps pdftops.pdf Bug687698.ps Bug689707.pdf mspro.pdf None of these are listed in the commit comments for r9852.
Created attachment 5231 [details] 9851.tif Output from Ghostscript r9851.
Created attachment 5232 [details] 9852.tif Output from Ghostscript r9852.
Created attachment 5233 [details] acrobat.tif Output from Acrobat Pro 9.
> None of these are listed in the commit comments for r9852. These difference were not detected difference at the resolutions developers use for regression tests. Can you and/or Ralph add the low resolution tests to the cluster runs?
We can recover the missing data by defaulting fill adjust to .5 instead of .25, if we want to air on the side of not losing data, note fill adjust will be .5 if the resolution is greater than or equal to 150 dpi (see gs_init.ps). Indeed if a customer complains about missing data they can simply lower the threshold such that fill adjust is .5. The changes needed to fix the fill code correctly (see #690620) will not be available this release. Also, I don't know that we have any 72 dpi customers, do we? I'm not inclined to revert the change for the release, but I'll let you and Ralph decide.
temporary fix in 9882.
and r9892.
With the change referred to in comment #7 most files now show with minor differences or progressions. Two that show as regressions @ 72 dpi are: Bug687472.ps puzzleware.ps
Reassigning to Henry to see if an improvement can be made to the regressions listed in Comment #8.
I believe Robin Watts addressed the fill adjust issues. Assigning to him for double checking.
I believe this is fixed. Certainly the original file for which the problem was reported is now underlined correctly.