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)
NOBR to remove a 'soft-newline' where it would otherwise be generated?

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".

Update: All the files in the relevant category should now be uploaded, so closing out this request, but if additional volumes or bad uploads come to light, feel free to re-open.

I wasn't sure what tickets had been filed regarding the large file upload issues from Special:Upload..

I have not filed a specific phabricator ticket for the Special:Upload upload by URL failing (in respect of large uploads), as I was told this was a known issue already.

Approximate number of remaining volumes is around 120 or so, mostly pre 1950.

In order that is some standardisation in respect of naming and metadata , ( I hope the use of template style syntax for parameters is acceptable.). Is this detailed enough?

Fae may be able to advise on which volumes are still to be uploaded, as they have access to the logs of thier own scripts.

Related-
It's taken multiple attempts to get - https://archive.org/details/catalogofcopyrig263libr
The PDF just deoesn't want to RELIABLY upload , even when I use a chkunked upload...
It fails repeatedly...

Rendering or transcoding an uploaded TEX file (or markup) to PDF (on the server side) would also be an acceptable compromise, and I have amended the task description accordingly.

(with apologies for the convoluted process involved in providing the expanded explanations)

With BR you get :=