Sumatrapdf: Logical page numbers corrupt in encrypted PDFs

[rdsqrt]

Customized page numbers show up corrupted in encrypted PDFs, and don't work for "Go To".
I'm seeing the same result with two encryptors: new QPDF, and old iText.

Only tried AES encryption. I think it was the same with 128 and 256 bits, though maybe a different sort of corruption.

Works fine in Foxit Reader v4.

Sample PDF, password is "password".

[GitHubRulesOK]

Tried in several viewers most would not navigate like SumatraPDF they showed corrupted strings ending 6, 7 & 8 Table of pages having been badly garbled by encryption once decrypted the page numbers return correctly to 6 7 & 8 both in SumatraPDF and others
unlocked 678.pdf
Note that edge will show them as 1 2 3 if that's the way you like them numbered

Whilst Acrobat Reader will tolerate the encryption and let me save the older contents in newer forms etc. My trusty Full Acrobat editor complains these are not true Adobe PDF files and thus I have to suggest we classify these encrypted TOC files as not valid PDF even if some applications including Adobe and SumatraPDF tolerate most features.

Best compacted result was saving from chrome but like most browsers including Edge etc. that converts pages 6-8 down to pages 1-3
From Chrome without password.pdf

[SumatraPeter]

Like Edge, the latest MuPDF 1.14.0 too displays the page numbers as 1-3. However it's interesting to note that Firefox's PDF.js has no problems at all displaying the page numbers as 6-7.

[rdsqrt]

It works okay on Xodo's Viewer (Android), which is based on PDFTron.

Even if it's outside of the standard for some reason, de facto support isn't rare, and it makes sense.

[TamirEvan]

The MuPDF viewer (and presumably Edge and Chrome) only shows the page indices. The expected "6-8" are actually page labels (see section 8.3.1, p. 594, of the PDF 1.7 reference), which MuPDF doesn't currently handle (Bug 695351). SumatraPDF works around this by getting the page labels entry directly.

The page labels get corrupted because the root version and OCG objects are loaded in the docment initialization phase, before a password could be validated (or even requested), and other objects get loaded (and decrypted) along the way, including the page labels, potentially corrupting them.

I reported a related bug on the MuPDF Bugzilla (Bug 701559 - mutool clean garbled page labels in AES encrypted PDF file). Towards it's resolution, one patch has already been committed to their main repo, and a second one is awaiting testing and review.

For SumatraPDF, I have "backported" the first patch, and a currently uncommitted version of the second patch, on my issue-1144 branch. If anyone wants to try it out, binaries are available.

This is what I get, with my applied patches:

[SumatraPeter]

@TamirEvan: Thanks for the investigation, explanation, bug reporting and patching! It would be great if someone like you could help restart active development of Sumatra... More than anything an update to the latest MuPDF version is _sorely_ required.

[GitHubRulesOK]

@TamirEvan you may have noticed @kjk is updating SumatraPDF to latest MuPDF however this bug is still there are you in a position to add your corrections as a pull request to recent commits, it would be nice to have closed this issue before next formal release.

[kjk]

When mupdf merges fix by @TamirEvan , we'll import it.
After the big merge updating to latest version of mupdf should be relatively painless.

[TamirEvan]

@GitHubRulesOK The first patch I mentioned seems to be included in the recent update of the MuPDF code (in SumatraPDF). The second patch is still awaiting testing and review. Like @kjk (if I understand him correctly), now that we're using a more recent version of MuPDF, I'd prefer to wait for the second patch to be committed upstream, and then import here.

@kjk The still pending fix isn't by me, but by Sebastian Rasmussen. I only backported it (along with the first patch by Tor Andersson) to the version of MuPDF being used at the time. (I probably should have been clearer about that, instead of relying on the links I gave to provide those details.)

[GitHubRulesOK]

@kjk still not included in latest update so perhaps tag as known MuPDF bug