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.

Links between ebooks and links in and out of ebooks should be supported. It would be wonderful if you could specify a link in an ebook or webpage that would take you to a precisely specified word sequence within another ebook. Links like this would allow the incorporation of ebooks into the general conversational structures of the web. Maybe one of the knowledgeable commentators on this thread has a viewpoint on this topic. Is it already possible?

Aren’t HTML5 and XHTML5 being developed concurrently?

Anyway, HTML vs XHTML, pretty sure there are others more knowledgeable who can comment on this but here’s my 2 cents. HTML is too darned permissive. That really is the basic problem. When you look at it XHTML is just HTML with additional markup – useful since it makes reading easier for *machines*. Yes, the browser on your Core 2 Duo PC makes quick work of HTML files (even badly coded ones), but the same can not be said for, say, the Sony PRS-505 with its 200 MHz processor.

You’re proposing a new format which will only add to the confusion. epub’s not perfect but it’s a start. Refinements can come later. It’s extensible so it shouldn’t be that difficult to modify.

Also, with increasing popularity, there will be more tools available for epub creation and editing.

More content is being published in epub. Now if only we can convince publishers to get rid of DRM while they’re at it.

I think it would be better to have an open-source effort with a strong lead (Adobe?) instead of the design by committee.
Also it would make more sense to me to standardize style-sheets. The style-sheet would be implemented differently for different devices taking into account their characteristics.
So if I want to write a book I just worry about the text, select a few predefined styles and it would actually look good.

The Sony ebook readers and the iPhone/iPod Touch already have support for epub. In the case of the iPhone/iPod, Stanza by Lexcycle is one of the apps available which you can use to read epub and that’s what I use. I do believe all standalone ebook reader apps available on iTunes support epub.

Kindle, well Amazon owns the mobi DRM, I think, so that one might be a bit more difficult. One of the ways Amazon will be forced to include native support of epub in the Kindle is if epub became the industry standard.

So the real question is: Can epub format as nicely and easily as HTML? If so, then the next major hurtle will getting devices (Kindle, Sony, iPhone, etc.) to read epub. Compatibility with the desktop or online is nearly worthless for long texts. Could you read Peter F. Hamilton’s Night’s Dawn Trilogy (3000+ pages) in epub on your desktop? Technically, yes, I suppose so, but few people would try it, whereas there is no problem on the Kindle or Sony. I can’t speak for every one, but for me anything more then 5 to 10 pages is too much to read on a desktop or online.

Unless epub can create nicely formatted texts on the popular devices it will not become the mp3 of ebooks.

And there really should be one general format.

http://tinyurl.com/http-EpublishersWeekly-net

This link works; the link in my previous post is broken due to the line length.

MP