DocBook to ePub

[Pavel Sanda]

On Fri, Jan 29, 2021 at 06:38:30PM +0100, Thibaut Cuvelier wrote:
> As promised, I started working on ePub output, building upon the new
> DocBook output.

Generally looks fine, thanks for the effort!

> Here is a script that performs the complete process of taking a DocBook
> file and generating the ePub. It has several dependencies:
> 
> - an XSLT processor:
> 
>    - not xsltproc (http://xmlsoft.org/xslt/xsltproc2.html): available for
>    most Linux distributions, I guess it is available by default on macOS, must
>    be bundled for Windows. I tried several versions for Windows, but an old
>    bug that should have been fixed in 1.1.24 (roughly 2010) is still there:
>    - I/O error : No such file or directory
>       - xsltDocumentElem: unable to save to
>       C:/Users/Thibaut/AppData/Local/Temp/tmp6c2i6a7h/OEBPS/package.opf
>    - Saxon 6 (available for most Linux distributions, must be bundled for
>    Windows and macOS, requires Java). It's outdated software (circa 2005), but
>    newer versions are not 100% backward compatible, so it is still very widely
>    used. Other DocBook stylesheets would work on newer Saxon, but they are not
>    as reliable as the old ones (like https://github.com/docbook/xslTNG).
>    - not MSXML6 (Windows-only, mostly built-it, but not compatible with the
>    DocBook stylesheets ??? it wrongly errors with chunking) or .Net XSLT engine
>    (nxslt/nxslt2).
> 
> - the official DocBook XSLT stylesheets. Three parts are required: XHTML,
> XHTML5, and ePub. For now, I copied the needed parts in a patch. On some
> Linux distributions, this could be replaced by a version installed by the
> package manager (Ubuntu 20.04 has a near-up-to-date version, although the
> latest one has been released in 2016:
> https://github.com/docbook/xslt10-stylesheets/releases/tag/release%2F1.79.2;
> Fedora is up-to-date).

Java dependency is sad news. Is there some bug within xsltproc which we
can bump or ask devs to fix it so we don't need to stick with saxon in
long term? I looked at https://gitlab.gnome.org/GNOME/libxslt/
and the project seems to be reasonably alive (If I look on the correct repo).

> (By the way, these patches have been written on top of the 14 others I just
> submitted to the list: they should apply cleanly, but that's not 100%
> guaranteed.)

As far as I could see the only point of potential conflict are few configure.py
lines of configure.py, we can easily deal with that. I still maintain that it
would be better to postpone nonessential python changes post 2.4.

> It's open for comments :)!

Small technical glitches
- we will need to bundle those files into our tarball so Makefile.am entries
  are missing. (I can help with this once in master.)
- I think Saxon & stylesheets belong to 3rdparty directory
- we need to give instructions to packagers why we bundle the stylesheets and
  libraries (lib/RELEASE-NOTES looks as a good candidate) and make clear which
  versions are needed to work correctly.

Pavel