I think this was fixed with the Proofread page refactoring, but I am not sure. Can anyone confirm?

No, it wasn't fixed.

Hmm. As I recall, PRP uses a hard 1024px size for the "thumbnail" it requests. I am assuming this was a value picked as a sort of compromise between full fidelity to the user and various optimization concerns.

Provided that's a correct assumption… It occurs to me that since thumbnail generation from PDF files requires a trip through Ghostscript (10-20s execution time regardless of size), and that even for DjVu the extraction from the multipage format is likely to be the most time-consuming step, this may be a poor tradeoff. Even the largest scans are not much bigger than your typical average photo on Commons. In other words, requesting the full size of the page should not take significantly longer than a scaled down version, and the result should almost always not consume a disproportionate amount of client resources.

That would give the zoom function some actually higher resolution data to work with, and would resolve a few pathological cases where the downscaling produces unreadable results (typically due to way too aggressive compression settings in the original).

The new OSD viewer includes a tile layer at 2x resolution image (2048px).

Further fidelity is probably limited due to MW only rendering PDFs at 150dpi, regardless of the actual image DPI, but that's tracked at T224355.

Does that resolve this issue?