Related: T361323

https://bdh.bne.es/bnesearch/detalle/bdh0000258110
https://bdh-rd.bne.es/high.raw?id=bdh0000258110&name=00000001.original.pdf

I think this is related to T78703: Support query continuation for Nearby requests

That must be it!

@Xqt I thought I already gave an example, so I will copy the one from the description.

https://archive.org/details/A253315
https://archive.org/download/A253315/A253315.pdf
59.3M
chunk_size = 1024 * 1024

https://archive.org/details/obrascompletasyc19ameguoft
https://archive.org/download/obrascompletasyc19ameguoft/obrascompletasyc19ameguoft.pdf
43.7M
chunk_size = 1024 * 1024

http://bdh.bne.es/bnesearch/detalle/bdh0000207265
https://bdh-rd.bne.es/high.raw?id=bdh0000207265&name=00000001.original.pdf
312M
chunk_size = 1024 * 1024

https://archive.org/details/tesorodelalengua00covauoft
https://archive.org/download/tesorodelalengua00covauoft/tesorodelalengua00covauoft.pdf
122.7M
chunk_size = 1024 * 1024

"Revert" wasn't my best choice of words. Of course I'm not proposing we get rid of OSD.

over three years of this feature loss, and no interest in reverting (even though a voluntary user provided with a patch)

This wasn't resolved (I was wondering what the problem was!)

It would be very nice to have a "processing" indicator!

I did some tests at https://w3c.github.io/uievents/tools/key-event-viewer.html:

I updated the description accordingly

In T362502#9720490, @Uzume wrote:

If the issue goes away with a purge there isn't really an issue with the page anyway. The issue is with a stale page cache. If you manage to update a page with such an error in order add processing to catch and categorize such an error, then the error would already have gone away because you necessarily had to update the cached page by editing the page either directly or through one of its transclusions.

Also the issue seems to not be in the Proofread "Index" page but rather in the "File" page which are mostly on Commons.

Even though a dictionary with, 100,000 entries with 300 bytes per file_url/filename would use 30MB of memory. Hardly an issue if you want to upload 100,000 files at once.

My bad

Ok

The post_processor function is great and I use it now in my code. I see that this is way more flexible when uploading multiple files. In my case I work with one book file at a time, so no need to do that, and in my mind it looked cleaner to just grab something instead of defining functions and such.
But I insist, isn't even more cleaner to just be able to grab the filename using the file_url?

I think it's a little convoluted but after a while I managed to get it working for my specific purpose.

In T360837#9676200, @Xqt wrote:

Both UploadRobot.process_filename() and UploadRobot.upload() already gives the filename back to the calling process (which is UploadRobot.run() by default. I've no glue for what the last_filename attribute is good for. Could you pleas explain a bit more.

Can confirm:

1. that the problem is present both at Commons and every local wiki
2. ?action=purge on a local description page (e.g. Spanish Wikisource Archivo:Filename.pdf) solves the problem locally, but only after '?action=purge'ing the Commons description page.

In T284504#7140995, @Tpt wrote:

@Tpt Is there a technical reason for this?

The <pages> tag implementation fetches the Index: page content from the database. Using it in the actual index that is used by the <pages> tag will lead to the use of the currently saved version of the index page on e.g. preview. So, to avoid strange bugs for the Wikisource contributors, enabling <pages> in the index pages requires a bit more than just removing this validation check.

&action=purge seems to solve this issue. Can we search for other PDF files that have this issue?

I guess this is related, but I had never experienced this bug before, and yesterday I uploaded a lot of books, and at least 5 had this issue

Loss of mouse scrolling is a major problem right now, specially for big books with small fonts, where lots of zooming in/out and scrolling is needed.

I ended up creating a custom JS script on my side that added two links. The page+2 is specially useful

I support this, and in I've seen an implementation of this in other digital libraries

Also, it doesn't "remember" your choice. When you finally find a good one, then the next day it will be hard to remember which one was it ;)

I did some test using this script

In T358635#9584134, @Xqt wrote:

In T358635#9583971, @Ninovolador wrote:

In T358635#9583360, @Xqt wrote:

@Ninovolador: you mean that the content is loaded anyway even that flag is set to False?

It doesn't work at all. It does not work as a genetator. No prompt or console output, just hangs

No, it works, for example:

>>> import pywikibot
>>> from pywikibot.proofreadpage import IndexPage
>>> site = pywikibot.Site('wikisource:en')
>>> ip = IndexPage(site, 'index:Popular Science Monthly Volume 1.djvu')
>>> gen = ip.page_gen(content=False)
>>> next(gen)
ProofreadPage('Page:Popular Science Monthly Volume 1.djvu/2')

Maybe it needs a lot of time to load all the pages. But this is due to the sorting funtion; propose to remove that in https://gerrit.wikimedia.org/r/c/pywikibot/core/+/1007342

In T358635#9583360, @Xqt wrote:

@Ninovolador: you mean that the content is loaded anyway even that flag is set to False?

It doesn't work at all. It does not work as a genetator. No prompt or console output, just hangs

I have the exact same problem. I just needed an easy way to loop through PDF files in a Category and it cannot be done because of this bug... Why wasn't the patch implemented?

In T352524#9374563, @Samwilson wrote:

Maybe someone at Wikimedia OCR project can tell us how they manage to get the full resolution image from every page

The Wikisource extension uses the same image that's already in the Page namespace page (i.e. from ProofreadPage). The width of this image can be customized per Index page, but is usually somewhere around 1000 pixels.

In T301985#7720422, @Samwilson wrote:

Good idea!

What particular features are you using in the advanced mode? Because it might be a nicer workflow to actually make it unnecessary to open the advanced mode and to make those features available directly in the page editor on-wiki. For example, T294903 is about adding the crop tool to the main image viewer, and T279405 is for better language-selection.

I've now tried to change the tabindex myself, in my User/Common.js.

In T271958#8170354, @Tgr wrote:

Not being able to save unrecognized CSS is the entire point of TemplateStyles.

At least add the possibility of saving the page. Currently it blocks you for even doing that (other "invalid" code passes just as well)

I agree. The "smaller" projects deserve more recognition

Mainly crop tool, so it would be covered by the T294903 patch when (if) it will be implemented.

Total support. It's not a rare task, but it's very time-consuming if you haven't the right tools (in this case, a bot account with admin privileges and a proper script) .

For some reason, the bug isn't present here: https://es.wikisource.org/wiki/Usuario:Ignacio_Rodr%C3%ADguez/Testpage2