Sumatrapdf: Misaligned layers in PDF

[SumatraPeter]

This PDF (which is a 4 page excerpt from the original) looks horrible in Sumatra (tested with 3.2 and prerel-13073 x64). The black 'text'/inking layer (which is actually an image since the text isn't selectable) and underlying flat comic layer aren't being aligned properly for some reason:

Same PDF looks fine in Sumatra 3.1.2 (so it's a clear regression), Firefox (pdf.js) and ChrEdge x64:

[GitHubRulesOK]

The Background CMYK colour image is 150 x 150 dpi and appears to have some black objects in the correct position !

Initially looks like a black overlay is incorrectly scaled at 80% by MuPDF in the horizontal direction, the black layer looks like it was fax standard 200 x 200 dpi so no obvious reason for that 80%:100% (4:5) ratio !

It is odd that there are two additional black layers (one for different languages, so why the other?), but at least it suggests it is likely all /CCITTFaxDecode objects are affected, here I removed the rendered lingo layer but the extra K layer is still shrunk in the X direction. The authors intent to relax colour requirements in favour of precision locking the black foregrounds together seems to have backfired in MuPDF.

(SideNote: Peter this is just one example why showing multiple conflicting dpi info's would generally be of no use to the average user, looking at individual objects info can only be of value when analysing obj by obj) Re: requests to show more copious image info etc https://github.com/sumatrapdfreader/sumatrapdf/issues/1394# https://github.com/sumatrapdfreader/sumatrapdf/issues/498#

[GitHubRulesOK]

@kjk
I guess SumatraPDF can not distinguish if CCITTFaxDecode filter is working correctly or not, so this issue may need to be raised as MuPDF Bug ?

[kjk]

Reported as https://bugs.ghostscript.com/show_bug.cgi?id=702565

[GitHubRulesOK]

"Curiouser and curiouser!" Cried Alice (she was so much surprised, that for the moment she quite forgot how to speak good English)."

When we zoom in ! And for me thats 209+% !!!

Yet another oddity is that in MuPDF-GL 199z fails but 200z works !!
Why the different threshold compared to SumatraPDF using the similar lib?

[SumatraPeter]

When we zoom in ! And for me thats 209+% !!!

Same here in 3.2; how weird!

[SumatraPeter]

Fixed so soon by the MuPDF devs? Great! Waiting for latest daily to test...

[kjk]

It's already there.

"daily" is a bit misleading. Every change gets build and uploaded as the latest "daily" build.

It typically takes ~30 min from the time of change to show up as a new daily build (unless there is a compilation error or GitHub has issues).

I've recently added a link to the change on daily build page so that you can see on which checkin exactly is the daily build based.

[SumatraPeter]

I know, but it hadn't been 30 mins yet by the time I commented after your commit. I did check again a while later, but I think I got slightly confused by the date since the page said "built on 2020-07-16" and it was the 17th here. 🙂

P.S. Confirmed that the issue's indeed fixed, so thanks to you and the MuPDF devs as well for responding so quickly to this particular issue.