Page MenuHomePhabricator

Proofreadpage attempts to use images with non-integer pixel size
Closed, ResolvedPublic

Description

Some PDF files report now non-integer pixel size.
Proofread page attempts to use this non-integer size for underlying image on book pages.
IMO, the retrieved size should be rounded up or down before further use.

This is a problem if the proofreadpage wiki configuration does not allow to alter the default scan size.

Example:
File:
https://commons.wikimedia.org/wiki/File:PL_Doyle_-_Zaginiony_footbalista_(zbi%C3%B3r).pdf
Page:
https://pl.wikisource.org/wiki/Strona:PL_Doyle_-_Zaginiony_footbalista_(zbi%C3%B3r).pdf/9
Image link:
https://upload.wikimedia.org/wikipedia/commons/thumb/7/72/PL_Doyle_-_Zaginiony_footbalista_%28zbi%C3%B3r%29.pdf/page9-772.91666666667px-PL_Doyle_-_Zaginiony_footbalista_%28zbi%C3%B3r%29.pdf.jpg

Event Timeline

This problem coincides with deployment of MediaWiki 1.35/wmf.14 today, but I find nothing obviously connected in the changelog. A few changes mention touching calls to int(), but not in any context that would obviously be connected to this issue.

Also judging by change log, this is not a ProofreadPage issue (no changes to PP this release). @Aklapper can you suggest better/other projects to make sure the right people see this?

Judging by on-wiki reports this affects all the Wikisourcen.

This problem coincides with deployment of MediaWiki 1.35/wmf.14 today, but I find nothing obviously connected in the changelog. A few changes mention touching calls to int(), but not in any context that would obviously be connected to this issue.

Maybe, just non-integer image sizes are new feature (unsure if it is intentional) that canoot be handled properly by Proofreadpage

I do not think so. The actual file mentioned in that task has integer sizes; the non-integer values most likely originate from an older, outdated file version. So that is rather some problem with caching outdated values than with non-integer sizes. Just accidentally noticed at the same time.

T242517 seems to have fixed the problem. I believe that we could close this task. I don't see the point for ProofreadPage to have a workaround for this bug that is now solved and affects other parts of the MediaWiki platform.

@Ankry Please do so if you agree.

Xover claimed this task.

Since this seems to be essentially a dup of T242517 which was fixed by reverting; the part of the change that triggered this task was not an intended change in platform behaviour (it was an unintended side-effect of phan cleanup); and all the specific cases reported in this task have been resolved… I'm going to go ahead and "boldly" close this as resolved. @Ankry Please reopen if you disagree.