Topic on Talk:Reading/Web/PDF Functionality/Flow

@Ckepper asked about the potential benefits of PediaPress going open source with this project in this thread. I wanted to give them some good takeaways to bring back to their company as it relates to this specific project.

Commercialization of a given project is an important reason to want to keep it closed source. However, I believe it would impede the success of the renderer long term were it to remain closed source. As things stand, I do not think it will be as successful as Extension:Collection because, for starters, it would not be free to install for most. Small wikis would not be able to afford much in licensing. Open source also instills a kind of trust that any large company, nonprofit, or single individual can rely on. It shows you are so confident with your product that you will extend that to showing it for the world to see in its most basic form: code.

On a different note, as is reported on the company's website, "[you] offer consulting, customization, and support for advanced document transformation solutions." This is nothing small right here, and I am confident in that business model. If, however, you believe otherwise, there is still ways to protect copyright without going closed source. In this case, I would look to Chromium for guidance in what potential path you can take. Not every one of your ideas needs to be included in an open source repository, so you can still maintain the parts you want secret or just to yourselves.

The principle rendering service should, however, be available to the public to do bug tests and the like. It's a win-win. Consulting and customization are where the real money is anyways. You could also branch into hosting this rendering service for others similar to how you already offer print-on-demand books to any mediawiki-wiki. Wikis will always need to pay for this if they want the product beyond what is already offered out there.

Finally, it is a strong selling point for a company with such strong ties to the open-source movement! I hope this helps you make the right decision on this matter.

Thank you for your comment. After talking with colleagues and other stakeholders, we have made the decision to release mwlib.html as open source when the project is sufficiently mature. This should help to ensure its long-term viability.

Also, I enabled the new render server so that rendering on https://pediapress.com/collector should work again (and be more stable).

That's awesome news! Major thanks goes out to your organisation for its willingness to do that. If there is anything you all need from the community (like press releases*, bug testing, etc.) please reach out! I just tried the collector on Simple:Spooky Scary Skeletons, and I think it really looks great!! Very elegant! :D

*I run Wikisource News (en) now, so I can help with publishing and writing it!

I have added Wikibooks (en) and Wikisource (en) to the test renderer. The output is still far from perfect but PediaPress was never able to generate PDFs from those sites before.

Hi @Ckepper, is it possible for you to add Wikipedia (ar), Wikibooks (ar) and Wikisource (ar). It's going to be a good test for right-to-left issues.

Hi @Helmoony, I have added Wikipedia (ar). A few years ago (for Wikimania Haifa 2011) we created a LTR export with our old PDF renderer and that was really painful - especially since no one on our team knew Hebrew. You can start playing around with the export, but this is definitely not a priority for us right now.

Thank you Ckepper, I tested the version, it's not working great. When it doesn't show ''Failed to load PDF document.'', errors are mainly: text format should start from right, wikidata-based infoboxes are not showing wikidata data including OSM-based map, some terms need to be translated (e.g. Image Sources, Licenses and Contributors). But at least we know what we need to do now.

The render worked for me just now for arwiki. There are still some RTL issues, but I didn't see the "Failed to load" issue.

Is the source available so that we can contribute?

Not yet, I'd like to clean it up a little bit before making it available.

I hope you can release it soon. The book functionality is needed! Thank you for your quick reply!

I hear you. Maybe I don't do the full cleanup to publish it sooner.

That would be awesome! Ugly code that works is better than no code.

There are, among those of us who use MediaWiki to run KM systems outside of Wikipedia, some absolutely essential extensions whose code is hideous.

I'm glad you want clean code, but I would hope that you can release the code as soon as possible and then clean up the code later.

Yes, absolutely. A buggy alpha release v0.01 is better than no release at all. Thank you so much for keeping on with this work.

@Steelpillow, agree complete. Is there any progress? Current situation April 11, 2020 is at opening Book Creator "Due to severe issues with our existing system, the Book Creator will no longer support saving a book as a PDF." A collaborative work "will always remain freely distributable and reproducible" only if I can export into another free file format like into the most common book format pdf or odt.

@Charis I have not been following progress lately. There is a test server at https://pediapress.com/collector/ which you can try. Otherwise, Ckepper is the best one to ask, as they have been the voice of PediaPress here.

I also posted this on Extension talk:Collection but the failure page when trying to Download to PDF on my wiki lands here, so cross-posting.

Our wiki is running on MediaWiki 1.31.7 and using Collection 1.7.0 (af3a0b8) 14:23, 15 April 2018. The Download as PDF is constantly failing and directing the user to Reading/Web/PDF Functionality which doesn't specifically address the reason for the "Book rendering failed". Reading through Talk:Reading/Web/PDF Functionality doesn't clear up the situation much either. It does seem to indicate there is a new render server available at https://pediapress.com/collector but that doesn't seem to work for non-Wikipedia sites. The existing render server https://tools.pediapress.com/mw-serve/ does seem to still active.

Is the functionality via this extension dead for low traffic sites that don't need or cannot install (i.e shared hosting) their own PDF server?

I got my mediawiki2latex package in ubuntu 20.04 (GPL). PDF generation seems to work fine. Furthermore I got my own rendering server, that also works with non wikimedia sites.

https://mediawiki2latex.wmflabs.org/

the last LTS version of mediawiki that supported the collection extension was 1.30.x it has been decomissioned accodring to https://www.mediawiki.org/wiki/Version_lifecycle WMF have stopped any development of the collection extension according to https://www.mediawiki.org/w/index.php?title=Topic:Uxkv0ib36m3i8vol&topic_showPostId=uxsjbpkqfmgq1jyx#flow-post-uxsjbpkqfmgq1jyx

I'm still confused, sorry, because that doesn't seem to agree with Extension:Collection which shows

MediaWiki

1.34+

as does Special:Version both here and on Wikipedia, both of which are running on

MediaWiki

1.35.0-wmf.30 (6d5d990) 12:06, 4 May 2020

Reading between this discussion and the Extension:Collection and it's associated talk page doesn't help clarify the status of the extension but more importantly whether there is a render server that low traffic wiki sites can use so that the Download to PDF functionality works.

As ever, there is confusion between the collection extension or Book Creator and the rendering service. The old rendering service, the Offline Content Generator, has been pulled and the promised PediaPress replacement interminably delayed. Development of the collection extension/Book Creator also stopped, but it remains in use. It still generates a trickle of bug reports and issues, so periodically gets looked at to see if anything can be fixed. But this is pure volunteer effort and there seem to be no low-hanging fruit any more. Hope this helps.

what else is there

pandoc: also GPL but might require some lua or haskell programmer to make it work for your case

bluespice: from 2900 EUR per year.