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.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T280637 Disable the WS-Export extension on Hebrew Wikisource | |||
| Open | None | T294509 Include webfonts specified in CSS | |||
| Resolved | Samwilson | T274521 WS Export in hewikisource unreadable: Large fonts, translated (?) markup tags, many square boxes |
Event Timeline
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
- We are declining due to having fixed some issues and we're hoping to fix the remaining ones, which are subtasks. We've also identified that picking a default font and fixing the templates could mitigate some of the pain points as mentioned in T274521: WS Export in hewikisource unreadable: Large fonts, translated (?) markup tags, many square boxes
Comment Actions
As long as https://he.wikisource.org/api/rest_v1/page/pdf/חוק_זכות_יוצרים produces better PDF compared to https://ws-export.wmcloud.org/?page=חוק_זכות_יוצרים&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.
Comment Actions
We are still waiting for the WS Export extension to be disabled on the Hebrew Wikisource.
Comment Actions
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:
- T298226: Allow use of @page CSS for PDFs
- T298227: Add options to exclude Title and About pages
- T294509: Include webfonts specified in CSS
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" }
Comment Actions
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.
Comment Actions
This issue starts to be urgent. I just received an update from a state official. She said Parliament officials cannot use our files since the exported PDFs are invalid, and asked when the issue will be solved.
The site request was opened more than a year ago. We need the WS-Export to be disabled so exporting to PDF will work again.
Comment Actions
Resetting priority per https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_priorities ; removing Wikimedia-Site-requests per T280637#7209140 as no such configuration switch exists currently.
Comment Actions
Reviving this old task.
I'm not sure to fully understand. I read the original discussion on the local scriptorium: שינוי הקישורים של תפריט "הדפסה/ייצוא" and all the message here.
It's still not super clear but from what I understand, it's not really about fully disabling it. It's just (or at least mostly) about changing the sidebar, see the original comment on scriptorium « The change can be made by editing the sidebar by javascript code in Common.js (this is something I can do). Do any of the experts here know a more "correct" way to update the sidebar? » (AFAIK, Common.js is the correct way, right?).
Cheers,