Page MenuHomePhabricator

Disable the WS-Export extension on Hebrew Wikisource
Open, Needs TriagePublic


The WS Export extension doesn't work properly for the Hebrew Wikisource. See T274521 for details. Furthermore, it overloads Electron-PDFs "Save as PDF" links.

We ask to disable the extension on the Hebrew Wiksource.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Any update regarding the site request?

Sorry for the late reply! The issue is the WS Export links are part of Extension:Wikisource. I'm assuming we don't want to disable that as it will remove other unrelated functionality from your wiki. With some work I believe we can restore ElectronPDF just for Hebrew Wikisource, but I wonder if we can fix the issues at T274521 instead.

There is an outstanding question at T274521#7199273 that if answered could help us decide on next steps.

The WS-Export extension is not suitable from exporting single article as PDF. When exporting an article to PDF, our users expect a printable version of the article they are viewing. The WS-Export extension was designed differently: from the extension point of view, the exported file is expected to be used by eBook readers. Therefore, the extension assumes the text should be kept but its styling can be ignored. This design is not suitable for styled texts, such as those of the Hebrew wikisource.

To answer your question – for the WS-Export extension to work for us, it should produce files which are visually equivalent to PDF files created by the "Print to PDF" function of the browser. This is what Electron PDF does, so we ask to stick with the solution that works.

I am aware that "Print to PDF" creates PDF files with the text in the right place, but the logical order of the words within the raw stream may be lost. Naturally, it's better to have native PDF exporter, which creates files both visually equivalent to printable PDF and suitable to eBook readers. In the long term, when the WS-Export extension will support exporting to PDF while maintaining styling, we will be happy to re-enable the extension.

Samwilson changed the task status from Open to Stalled.Nov 17 2021, 3:16 AM
Samwilson claimed this task.
Samwilson added a subscriber: Samwilson.

Before moving ahead with this, I do want to figure out if all the bugs identified in T274521 can be resolved. @Fuzzy can you have a look at my last comment there and see what you think?

The key issues here seem to be around styles, and it seems that at least in some situations templates on Hebrew Wikisource are applying e.g. .noprint to hide certain elements, and that the handling between ElectronPdf and WS Export has differences with these classes.

NRodriguez added a subscriber: NRodriguez.
Fuzzy reopened this task as Open.EditedDec 8 2021, 1:06 PM

As long asחוק_זכות_יוצרים produces better PDF compared toחוק_זכות_יוצרים&lang=he&format=pdf, we insist on disabling the WS-Export extension on the Hebrew Wikisource. The WS-Export extension is immature for our use.

The progress done at T274521 is good but insufficient. I promised @Samwilson detailed explanation there.

ldelench_wmf added a subscriber: ldelench_wmf.

Discussed at standup: we have moved T274521 into the current sprint.

We are still waiting for the WS Export extension to be disabled on the Hebrew Wikisource.

Thanks for your patience. We're really keen to try to sort out the actual problems with WS Export.

As discussed in T274521#7586968, it sounds like these are the remaining high-priority tasks:

Does that sound correct?

Also, I notice that a default Hebrew font still hasn't been set, despite our discussion on that other ticket. It really would help, I think!

A default font can be set by modifying the Hebrew Wikisource's WS_Export.json with e.g.

    "defaultFont": "Yehuda CLM"

As previously stated, when processing single page, WS Export should produce a PDF file which is visually equivalent to the file created by the browser "Print to PDF" function. WS Export may be useful when processing a collection into PDF/ePub/Mobi/rtf/docx files. The tasks mentioned in the comment above are merely the first few steps on the long path to a workable and useful extension. And for now they are not set as "high priority".

I'd like to suggest another feature. The extension functionality must be configurable. For example, if some file types do not work properly, project administrators should be able to disable them with a special page.