GnuCash Documentation 2.4.1 in .epub and .mobi format

Geert Janssens janssens-geert at telenet.be
Sat Jul 9 04:28:23 EDT 2011


On zaterdag 9 juli 2011, SASAKI Suguru wrote:
> 2011/7/9 Geert Janssens <janssens-geert at telenet.be>:
> > I wonder if this script is required to generate the epub format,
> > or if it's just a wrapper around a generic xslt transformation.
> 
> From a quick view with this script,
> this script does:
> - XSLT transformation using xsltproc
> - zip these reesults into .epub
> 
> So, basically, we can go whitout this script.
> 
> 2011/7/9 Geert Janssens <janssens-geert at telenet.be>:
> > While googling, I found this:
> > http://www.ibm.com/developerworks/xml/tutorials/x-epubtut/section5.html
> > 
> > It is basically the recipe to create an epub file from the docbook
> > source. Looking at it, it seems to consist of
> > - one xslt transform using the epub xsl from docbook
> > - generating a proper zip file with mimetype included
> > 
> > At first sight this doesn't seem to be too difficult to transform in a
> > makefile ruleset. We may be able to avoid a ruby dependency in this way.
> 
> Yes, in .epub generation, we can avoid a dependency on Ruby in such a way.
> But in .mobi generation we *can't avoid* a dependency on calibre (and
> thus on Python).
> 
> So if we merge *only .epub generation* into build system,
> I'll investigate a way to go wihtout such a script (and thus Ruby),
> but if we merge *.mobi generation as well*,
> we can rely on Pyhon and writing dbtoepub in Python is sufficeient.
> 
> Minimizing the dependencies are a good way to go,
> but we are not neacessarily stoic about using other tools.
> I guess, Python is almost a standard tool on Linux and other enverionments,
> so depending on Python is not bad.

It's not a standard tool on Windows unfortunately. Our Windows build currently 
doesn't use python and the debate is still open whether it should or not. I'll 
skip the discussion about it for now, that's not the point I want to make 
here. But I think we can agree that Windows is our most limiting platform 
here.

For me, I would like to see the epub format supported by default. Given our 
little investigation, we can assume that this is possible with the tools 
already available both on Windows and the other platforms (shell script, 
xlstproc and zip). So supporting epub is a no brainer as it doesn't introduce 
new dependencies.

The mobi format on the other hand is slightly different. I'll write it slightly 
more elaborate this time so others following the thread get a clear view:
The mobi format is not one supported by the docbook stylesheets. To create a 
mobi file, an external script is usedinstead to convert an epub document to a 
mobi document. This script is part of  the calibre package, which is a gui 
tool to manage your ebook collection. It's a nice program by the way, written 
in python and runs on all major plaforms.
The disadvantage is that calibre is not installed by default, so the script we 
need is not readily available. This is not necessarily a problem of course.
The other disadvantage is the dependency on python, which is not installed by 
default on Windows. So if we want to build the mobi files on Windows, we have 
to make sure python is installed. I suspect only a few people will be 
interested in building the GnuCash documentation the mobi files on Windows for 
several reasons:
- most ebook readers I have encountered support the epub format
- calibre does the same conversion automatically if it detects a device that 
doesn't support epub but mobi instead.
So adding a python dependency in the build chain just to be able to generate a 
rarely used document format seems a bit out of balance.

Having said all that, I'm still for adding mobi support to our build scripts. 
So here's what I propose:
We can make it an optional format via our configure script. At present we have 
a simple configure script that checks for the necessary dependencies and 
generates the proper makefiles from there. There's no conditional in there 
until now, but it can easily be added. Suppose we introduce a --with-mobi 
conditional. When someone runs ./configure --with-mobi:
- configure will test for python and calibre and issue an error if either one 
is missing
- setup the proper build rules to convert an epub document to a mobi document

With that, I think we have the best of both worlds. epub freely available, and 
mobi for those who want to build it themselves. And yet the Windows build 
doesn't get any more dependencies.

Does that sound ok to you ?

Geert


More information about the gnucash-devel mailing list