In respect of English Wikisource this was implemented as user-side script, so closing this ticket.

My suggested wording would be "An existing file is already linked to the IA identifier 'foo00foo': File:bar.pdf. It is not necessary to upload a duplicate file, unless it is to resolve a technical issue, missing or illegible content." which enumerates the reasons where uploading apparent 'duplicates' wouldbe permitted.

Adding another example/test case -
https://en.wikibooks.org/w/index.php?title=User:ShakespeareFan00/Sandbox&oldid=3825254

Would recognition of the property concerned in the editor require a separate ticket, once the sanitizer supports it?

An alternative off the wall thought...

Given that for many of these files the metadata WOULD include the substantial text layer that is only of relevance for specific tools (like Fae's copyright message hunter on Commons) or Proofread Page at Wikisource, would it be technically feasible to move the text-layer to being something that is NOT supplied unless explicitly requested, meaning that having to request explicitly would mean changes to a small number of tools as opposed to having to rewrite many if the default was to exclude the metadata entirely by default?

Would it be feasible to add some kind of 'callback/unattended' functionality for PAWS sessions, where you know a task using it will take a long time?

A suitable extension exists.

The two scripts concerned. -
https://en.wikisource.org/wiki/User:Inductiveload/Jump_to_file.js
https://en.wikisource.org/wiki/User:Inductiveload/page carousel.js

An offset or hi-res/file scan toggle would be useful ( Related functionality that's already provided via the third party page carousel script you also wrote.)

Closing out as based on a discussion , A work around using comment exists..

Or a behavior switch? (https://www.mediawiki.org/wiki/Help:Magic_words#Behavior_switches)

This was discussed on a Wikisource Discord.

Moving to low priority as there are potentially (albiet tiresome) work-arounds for the specfic issue concerned.

@Aklapper : Thanks for re-opening with apologies for some earlier frustrations or comments.

Confirming solved as of 2021-01-21 . Bug can be closed if this checks out.

Closing as invalid, Wrong tool for an extended length task.

In T134469#6704686, @Xover wrote:

You mean add layout container options for LST ? your text syntax above is essentially {{#section: Pagename/Foo}}

I would add that being able to 'partition' a page would also be useful in order to help OCR content that was tabular data or columnular in nature.

The example listed at the opening of this , is no longer in the Sandbox linked (and I did check past revisions, if an admin wants to check deleted content feel free), so this should be closed unless someone wants to come up with a new example.

Some loss in conversion to PDF or DJVU is inevitable, but Commons shouldn't prevent attempts to improve quality.)

Technical query.

Some more information on WASM here - https://webassembly.org

I am not aware of any yet., so if this ticket is kept open it should be marked as low priority.

WASM = Web assembly.

In respect of recent template fixes I've been providing ( Protected page is first followed by the sandbox . If you want fuller diffs for the pages before they were sandboxed please LMK.)

Confirming that this issue is still present as of August 2020.

Kahholz: Would you be interested in porting this Gadget to English Wikisource?

If you want to set up a mechanism to pull HUGE quantities of JPEG/JPEG2000/TIFF scans from IA, I'm more than open to the suggestions you mention here. :)

The ticket at Ghostscript suggested this : https://bugs.ghostscript.com/show_bug.cgi?id=702531#c1, which is a tweak to the invocation used to render the PDF. It also suggested using something called convert. (On Wikimedia this would be the Thumbor library ?)

Question: When it resizes, is Thumbor using a rescale or a Resample?

From some investigations of DPI levels using IfranView, I think this 'bug' can be solved by upping the DPI for generated images on PDF.

Is this also related to T224355 ?

@AntiCompositeNumber : Can you consider some test renderings at 150, 300, 600 and 1200 dpi respectively?

Option 5. Provide an option in the Image handling at mediawiki to render at a higher DPI. ( I have a strong hunch these are likely to have been scanned at least 300/600 dpi if not higher. I wonder what is typical in an archival situation?)

Logged upstream as https://bugs.ghostscript.com/show_bug.cgi?id=702531

1. Batch uploading the Djvu equivalents for PDF files is feasible, If automated ( Anyone want to write a script?). However in some instances I am wondering if the DJVU's at IA are generated from the PDF.. and thus might inherit related issues.)

For comparison:-

(I'm also checking the output in gsview , which is taking for... absolutely... e..v..e..r to render even single pages.)

Aklapper: Internally PDf.js decodes JPEG images so it can render them in the viewer.

[strike]The viewer code Mozilla Firefox appears to be using is - https://github.com/mozilla/pdf.js (Apache license) . [/strike]

@Aklapper : Thanks for the update.

Fae: I've also noted a quality issue with some PDF uploads,
https://en.wikisource.org/wiki/File:Catalog_of_Title_Entries_of_Books_Etc._July_1-July_11_1891_1,_Nos._1-26_(IA_catalogoftitleen11118libr).pdf
being one, Where the page image displayed in the interface is of a lower quality than that in the actual PDF ( compared to a direct display of the page in Adobe Reader, which was also unable to export a usable image to older image viewer tools.)

Not necessarily a check suitable for all uploads, but comparing a new upload against a hash for an 'office' actioned removal might be useful. You could compute an SHA-1 on a new upload and compare it against ones previously removed. (Like is done in ehcking for duplicate uploads). This could prevent accidental re-upload of previously removed material, with a suitable warning to the uploader.

I'd like to able to do a "prefix" filter as well. On Wikisource, goups of Lint errors typically need to be fixed across a number of Page: for a given Index: and at present the Special:LintErrors page doesn't let me do that level of search "granularity".