Well, if you use an ePub editor like Sigma, you don’t have to worry about all of that. Create the ePub file using whatever tool you want (I use a program called eCub to create the basic ePub file (You can feed it txt, html, or xhtml files) and then tweak it with Sigma. The end results work in iBooks, Stanza, and any other epub reader I’ve tried.

In my honest opinion, with HTML5′s growing mature, EPUB will be useless except for DRM.

https://github.com/jric/epubtohtml

“Old HTML (pre-frames and pre-CSS) works fine everywhere, even on the most lowly of devices or simplest of web browsers.”

Exactly. But…

“Sure, people who write bloated, slow-to-view web pages love CSS and a zillion tags at their fingertips…”

And guess who designs ebook readers.

Thus, XHTML is NOT inherently more “verbose” than HTML. If one observes “verbosity” in an XHTML document, it is not because it is XHTML, but rather that it is poor markup probably converted from Word — such verbose markup can be expressed in HTML 4.0 just as easily.

There only 2 rationales for epub that I can see: the zip container to carry multiple files (images, etc), and for foisting DRM onto readers. Oh, I guess there is a third rationale: to make sure consultants have a continuing source of income producing ever more complex formats.

The container thing is fine. It is easy to deliver html ebooks as zip files.

The DRM argument should be dead already. Any format that survives any length of time into the future will not have DRM. All locked books are absolutely guaranteed to lock their owners out later.

The consultant thing? I’m kinda okay with them endlessly thinking ever more complex formats, but there really is no reason why we should mindlessly follow them.

There’s one slight exception to the my dismissal to the extra things in XHTML, and that is the possibility of using mathML, SVG and a couple of other such extensions, which would be a good thing. Unfortunately they are still pretty-much vaporware even though the syntax for them is well developed. Commercial markets don’t like non-proprietary formats.

Sadly it all comes back to finding a way to squeeze more money out of the end-users or the publishers.

I am very disappointed with Android’s lack of support for basic features.

I know my program is not extremely user friendly. I would like to get around to creating a GUI someday (is there anybody that would like to help with that?), but for the time being, all one has to do is create a gutenberg tag (named after the site named after the man) and type:

perl libreria.pl [your book file].txt


Depending on the layout of the book (and this varies a lot!), it should work without much other information and generate a folder named with the title of the book. If not, it can be told what to look for with HTML style attributes in the gutenberg tag. The folder can be copied to any device with a web browser that can access local files. The files should display nicely on any small screen.

As for the zipped files, were those addon programs? Or was zip a stock feature? I would really like to see Linux phones include gzip and bzip2 as well as zip. I would also like to see browsers read archives as folders. That way, the files could remain as a compressed unit, but be accessed as uncompressed. On modern phones, the speed difference should be negligible. That would pretty much eliminate the need for ePUB and dedicated e-book software, though.

Also, the lack of archives makes transferring files from one device to another over Bluetooth difficult. Since I do a lot of testing, every restriction that costs me time makes things much more difficult. Not only that, but for Public Domain books, why not have the ability to easily share them with friends?

Not having used your script, what variety of HTML does it generate? As discussed above, XHTML 1.1 would be a good guide to follow, as you get clean, unambiguous code. I’m not setup for Perl right now – how about posting a link to a sample of your script’s output for the curious?

LuYu Says: “I have never seen a device, PDA, or phone that had the ability to access zip or any other type of archives.”

There were Zip utilities for PDAs at least ten years ago. Also, uBook has had the ability to handle Zipped ebooks for as long as I remember. Not owning a PDA any more, I no longer use uBook.

In my experience, Opera is the best. NetFront and Ericsson’s stock browser are usable but lack important things such as non-Roman encodings and fonts with special characters. All three of these browsers have the ability to constrain text to the available screen width.

Bad mobile browsers are: minimo (does not work, really), Konq-e and other webkit browsers — including Safari from what I have seen (lack ability to constrain text), Android’s browser (also webkit), and PocketIE (sssllloooww). Except for PocketIE, none of these browsers can access the local disk (Android’s browser actually refuses to reconise file:/// links!!), so if you wanted to save your HTML e-books to your memory and read it from your phone, you are out of luck.

I have never seen a device, PDA, or phone that had the ability to access zip or any other type of archives. This is unfortunate because transferring files as a unit is always nice. If this feature existed, I doubt very much that dedicated e-book software would even be needed.