Bug 707847

Summary:	bad rendering of qr code
Product:	MuPDF	Reporter:	Krzysztof Kowalczyk <kkowalczyk>
Component:	mupdf	Assignee:	MuPDF bugs <mupdf-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	robin.watts
Priority:	P2
Version:	master
Hardware:	PC
OS:	Windows 10
Customer:		Word Size:	---

Description Krzysztof Kowalczyk 2024-06-26 21:20:14 UTC

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

Comment 1 Robin Watts 2024-08-02 16:15:44 UTC

I have a bugfix for this in testing.

Comment 2 Robin Watts 2024-08-05 15:16:59 UTC

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!