The following commands render page 3 of a file in page and clist mode respectively: debugbin/gswin32c.exe -sDEVICE=pbmraw -dFirstPage=3 -dLastPage=3 -o out.pbm -r300 -dMaxBitmap=0 ../tests_private/comparefiles/09_47N.PDF and debugbin/gswin32c.exe -sDEVICE=pbmraw -dFirstPage=3 -dLastPage=3 -o out.pbm -r300 -dMaxBitmap=80000000 ../tests_private/comparefiles/09_47N.PDF Call these renderings Pnew and Cnew. If we disable the fast thresholding code by editing gximono.c line 173 so that it never returns gxht_thresh_image_init, we can examine the results of the old halftoning code. If we rerun those jobs we can get Pold and Cold. At the current time (say commit b9e0722267e8770c01914da28f924cffcae1c0b8) Pold == Pnew == Cnew != Cold. Hypothesis: the Clist is transferring the y_phase (which should be 0) incorrectly. Accordingly Pold = Pnew = Cnew (cos the new code currently ignores the y_phase), but Cold (which uses the y_phase) is broken. With the proposed fix for halftone phase in place (I'll update the bug when it goes in): Poldfix = Pold = Pnewfix = Pnew = Cnew != Cnewfix == Coldfix == Cold So the fix moves the new code to be consistent with the old code in all cases. This is consistent with the hypothesis. Investigate some more.
I suspect page 20 of this is similar: tests_private/xl/pcl6cet3.0/C303.bin.pbmraw.600.1
I failed to update the bug as promised when the fix went in: commit dfbf92a35d2be0aaa35bdb301c0647deec55b054 Author: Robin Watts <robin.watts@artifex.com> Date: Wed Apr 11 19:37:07 2018 +0100 Attempt to fix vertical shifts seen in halftoning. Differences are evident between old (slow, non SSE based) and new (fast, C/SSE based) halftoning. This is not because of the SSE, but rather because of different calculations in the C that prepares the screen for the fast SSE based thresholding, specifically, I believe, to the calculation of the y offset into the texture tile. This commit changes the texture tile y offset calculation in the 'fast' code to involve screen_phase.y, in the hopes that this will better match the 'old' version. With this fix in, we see just a few PS/PDF diffs, but lots of PCL diffs (as I guess you'd expect, as PCL makes much more use of this kind of stuff). I've checked a random selection of them, and in all cases the new page mode renderings with the "fast" code match the page mode renderings given by the "old" code. There are instances where the clist rendering no longer matches the page mode rendering, but in the tests I've done the clist old code does match the clist fast code. So we are consistent at least. I suspect that there is something up with the way the y_phase is transmitted across the clist, and have opened bug 699209 to track that. Thus the current situation is that Page mode renderings do not match Clist renderings, regardless of whether we are using old or new code.
Created attachment 21791 [details] edit4.pdf Vastly simplified file. debugbin/gswin32c.exe -sDEVICE=pbmraw -o page.pbm -r300 -dMaxBitmap=1G edit4 .pdf && debugbin/gswin32c.exe -sDEVICE=pbmraw -o band.pbm -r300 -dMaxBitmap=0 edit4.pdf && md5sum band.pbm page.pbm convert band.pbm band.png && convert page.pbm page.png && start band.png && s tart page.png
The first problem reported here is solved by: commit f3c1d9b409c9add8a2bb31c049c3c65a10c3147d Author: Robin Watts <Robin.Watts@artifex.com> Date: Tue Oct 26 17:53:35 2021 +0100 Bug 699209: Fix tile phase used for image. When sending a monochromatic image to the clist, we end up using whatever tile phase was set rather than the more correct (0,0). The fix is to reset back to (0,0) if we are not using color. This causes 3 diffs in testing, all now match page mode rendering. The problem reported in Comment 1 remains.
The problem from comment #1 is fixed by: commit a3524c6d0b1315de80724768889c90a6c1683a83 Author: Robin Watts <Robin.Watts@artifex.com> Date: Fri Oct 29 17:50:16 2021 +0100 Bug 699209: Continued. Attempt to fix issue seen with C303.BIN In the PS and PDF world, images can either be imagemasks (in which case they are filled in the current gstate color), or they can supply different colors per pixel. Accordingly, if an image uses the current gstate color, the clist must write the halftone phase if the color might need it. If an image does not use the current gstate color, then the halftone phase should be written (because we can't tell whether all the colors are pure or not in advance). The current code copes with this just fine. Unfortunately, in the PCL world, we can be in the unholy situation where an image can use the current gstate color AND it can use colors information from the image. Thus we need to send the phase both in the case where the current gstate color might need it and when the image is not a masked one. This shows up various diffs, but I am spinning out a separate bug for them.