Allow downloading of the entire code, sections of code, and chapters of code, in EPUB, Word, and PDF formats

[waldoj]

There are two promising potential methods of providing EPUB files: ePubExport and "EPub". The former is a MediaWiki extension, the latter a PHP class. Elmer Masters took the "EPub" class and improved upon it for Free Law Reporter, specifically found here.

[waldoj]

Look at using EPUB Boilerplate.

[waldoj]

See the the PHPDocX library to generate DOCX files.

[waldoj]

PDFs can be generated with the promising-looking FPDF.

[waldoj]

These should be easy enough to create functions for within class.ParserController.inc.php, so we can generate all of these formats at the time that the importer runs.

The licensing for PHPDocX and FPDF is entirely GPL-compatible. I don't know about ePub-Boilerplate—it doesn't include a license, making it implicitly copyrighted and thus can't be included. @javierarce, are you willing to put a license on ePub-Boilerplate?

[javierarce]

Sure, what kind of license would work for you? GNU GPL?

[waldoj]

Anything GPL-compatible would be great! MIT and BSD are the licenses I prefer for my own work, which are both GPL-compatible. Thanks for ePub-Boilerplate, @javierarce—it's a real time-saver.

[javierarce]

Ok, I'll go with the MIT license.

I'm glad you find this project useful, Waldo!

[waldoj]

Wonderful—thanks so much for doing that.

[maxfenton]

👍

[krusynth]

Propose moving Milestone to Future. It's not a huge amount of work, but I don't know that it's worth the effort. I'm also a little concerned about "stepping on toes" by releasing a non-official copy of the code as a single document in a common format like this.

[waldoj]

I'm not concerned about stepping on toes—we can make it a config option as to whether each of these is provided. Nobody needs to enable the feature if they don't want it. Hell, this whole project is about stepping on toes. :)

Realistically, of course, this needs to be broken out into three tickets. I'm inclined to provide functionality for just one format in 1.0, and push the others back to Future. (That'll create the framework to support the others down the line.) The question is, if we're going to support just one format, which should it be? I'm leaning towards PDF. That should be straightforward, moreso than ePub or Word, with plenty of existing libraries to support it.

[krusynth]

+1 for PDF. Though that requires generating a one-page HTML version first in most libraries, and increases the dependencies to run the app.

[krusynth]

Ok, the hard part of this is done – I've refactored the entire export process into a plugin-based system to generate files. This will make creating new export types much, much easier. Now all that remains is to use this to generate the new file types. The generation of the all-in-one files should happen in the new finishExport event.

Here's the branch:

https://github.com/statedecoded/statedecoded/tree/export-refactor

[krusynth]

That should be the bulk of the work for generating exports. Most of the new formats rely on pandoc to do the lifting from HTML. PDF generation is REALLY slow, so I don't recommend that for most people. It also requires some hurdles to get pdflatex installed.

The only thing left here is adding new hooks to the plugins to show the download links dynamically on the relevant pages.

[waldoj]

This is great! Presumably we should hold off on merging this branch until those hooks are included?

[krusynth]

Yup! Hoping to get to that today/this weekend.