Originally reported: https://github.com/sumatrapdfreader/sumatrapdf/issues/4321 Test file: https://github.com/user-attachments/files/15812456/test.pdf background of qr code image is different than in e.g. Adobe Reader
I have a bugfix for this in testing.
Fixed with: commit 160a1effa36a8de9ed2a3ded33a549ee19b85f1c Author: Robin Watts <Robin.Watts@artifex.com> Date: Wed Jul 31 19:01:28 2024 +0100 Bug 707847: Update gray.icc. The bug basically boils down to devicegray and devicergb not matching up in quite the way you'd expect. Given the following PDF fragment: 0.851 g 0 0 50 100 re f 0.851 0.851 0.851 rg 50 0 50 100 re f you might reasonably expect them to render the same when drawing to an RGB device. Indeed GS and Acrobat give such identical results. MuPDF gives a different result due to the gray.icc in use. GS has: default_gray.icc default_rgb.icc default_cmyk.icc and mupdf uses the latter 2 as rgb.icc and cmyk.icc respectively. Oddly, mupdf is using ps_gray.icc from gs as gray.icc, leading to a mismatch. To solve this bug, we change gray.icc to be default_gray.icc too. GS has additional tricksy code to swap ps_gray/ps_rgb/ps_cmyk in and out when we enter/leave softmasks. Presumably this is important to get correct rendering of luminosity softmasks. Maybe that's why MuPDF was using ps_gray? This seems a half-hearted solution at best. At least we are now consistent. An alternative solution would be to use ps_gray/ps_rgb/ps_cmyk from gs as our gray/rgb/cmyk. Presumably there are reasons why Michael felt that was inappropriate for GS. Doing the same swapping of profiles is trickier for us than for GS, as GS knows the order of operations due to the way in which it is called. MuPDF is much 'freer' in that multiple threads might be rendering different things with the same device profiles. I propose to ignore this potential problem until we actually have an example where it matters. Thanks for the report!