Slashdot Mirror

"when the document is rendered by a Reading System without scripting support or with scripting support disabled, the top-level document content must retain its integrity, remaining consumable by the User without any information loss or other significant deterioration."

- http://www.idpf.org/epub/301/s...

HTML5 is a terrible source format because it is predominantly a visual markup, not a semantic one.

Actually, HTML elements in ePub have defined semantic roles, primarily to allow assistive technologies to make better use of the content.

If programmers designed eBook formats, they'd have vector graphics support.

So true.

It makes me sad that the article doesn't even mention which epub version (1, 2, or 3) the author was comparing it to. Most new books are in 3, but there's a ton still out there at version 2. Not to mention that the International Digital Publishing Forum [IDPF] is an active standard and will continually be updated for the foreseeable future. Some quantitative data would be very useful when comparing proprietary and open standards, especially as each format (and distribution system) have strong pros and cons. Personally I'm all for fully open standards for any data type, it'd take a lot of superior features to draw me into a vendor lock-in system.

Homepage for the EPUB standard.

Why do I recommend EPUB so highly? Besides the fact that it's an open standard, that is? ;) Well, Wikipedia has a good comparison chart of e-book formats versus the e-book readers that are covered. It shows that the only format with a broader range is straight text. (Yes, it even beats out PDF and HTML.)

There is a plug-in available for OO.o and LO called Writer2ePub that will save directly to EPUB, btw. The main support channel is through a MobileRead forum.

May I suggest that you spend some time browsing MobileRead before making any final decisions? In particular, I would like to call your attention to the Calibre, Sigil, and OpenInkpot forums.

Next, there is a package called eLyXer which does a pretty good job of converting LyX files to XHTML. EPUB relies heavily on a subset of XHTML as part of its specification so I've been experimenting with a new toolchain.

I write my documents in LyX to get good looking PDFs, then use eLyXer to get XHTML, then use the import/convert function of Calibre to get a good looking EPUB, then use Sigil to fine tune the final output. Since both eLyXer and the e-book conversion utility packaged as part of Calibre can be called from the command line, it would be possible to automate some of that work pretty easily. I haven't bothered with that as my needs are only for occasional use at the moment.

Another alternative would be to just write the journal in Sigil. That would probably mean abandoning PDFs and paper output entirely, though.

P.S. How come you didn't have an article focussing on Arduino in your initial issue??

ePub I believe is partly documented but 100% owned by Adobe and only for Adobe's benefit.

The standard, DRM-free EPUB format is wholly documented, and is controlled by the International Digital Publishing Forum (IDPF), not Adobe. You can find the complete specs right here: IDPF EPUB Specifications.

The additional layer of encryption used by e.g. Barnes & Noble for their NOOK isn't exactly publicized, but any reader which can handle DRM'd EPUB files should also be able to handle standard ones. The NOOK certainly does.

Gladly. The problem with most formats is that they can only be read by proprietary readers, and are thus locked in. The most "free" format is obviously plaintext, then html. Some people use rtf (windows-specific, and less support on other platforms), lit (proprietary) and the various Sony, Amazon, etc formats like AZW.

ePub is XHTML for the page layout and CSS for formatting. It also has various other files containing XML metadata, and is put in a zip archive. The metadata is used to identify copyright information, author, contributor, year of release, and other important information. This means that library management tools like Calibre are able to easily organize your books, so you can find all the books written in 1996, or all books written by Asimov, or all science fiction, or... the possibilities are endless. Basically, it's a way of packaging well-formatted ebook pages with chaptering and tables of contents, plus metadata.

If you're interested, take a look at the ePub spec, it outlines all the formatting options. By searching around you can find a few quickstart guides to formatting and packaging ePub.
http://www.idpf.org/2007/ops/ops2.0/download/

Problem with automatic reflow-ability is widows and orphans, that book editors could and do remove from their paper (or pdf) works.

It seems to be trivial to write a layout algorithm that avoids having too few lines on a single page. I'm not sure, but I suspect TeX would have some already, so it could be just readily ported. I know that many PC e-book readers use TeX algorithms, too, and at least one hardware device (LBook).

In any case, if an automated solution does it right in 99% cases, I can live with the remaining 1%. It is a very minor inconvenience when compared to the ability to change font face and size at will, rather than being stuck with whatever the publisher liked most. Font size in particular is a huge issue for people with less than perfect eyesight.

he point of the "e-reader" is that the pages you get are identical to the print version

Where did you get that idea? No e-book reader that I've seen, neither a dedicated hardware device nor a software reader, has this as a design goal. Given that the screen has dimensions rather different from a typical book, and also given that font size has to be larger to be legible (since resolution is currently limited to ~170 DPI with eInk screens), any fixed-layout books would have to be specially produced for those readers, different versions for different screen sizes.

If you want reflow, then why not just have all books be in HTML, and have eReader just have a web-browser? (or how about html.gz if space is an issue?).

.html.gz isn't enough, as you also want to be able to package images with the book.

That said, EPUB effectively is a .zip file with book in XHTML 1.1 Strict + CSS 2.0 (or rather, a well-defined subset thereof, since you don't need it all for a book). The package also contains a separate XML file with its own schema for book metadata, and table of contents - the latter in particular is so that every reader can represent it in the way most convenient and accessible given its presentation constraints (screen size etc) - rather than just a bunch of nested lists with links.

Or at least, it is compared to the Kindle. Sony will read PDF files and EPUB files. (EPUB is an open standard; an EPUB file is really a zip file, containing a few XML documents that describe where everything is, and then either XHTML or DAISY/DTBook content).

It's VERY easy to copy content to the Sony readers (shows up like a USB hard drive, or copy content to an SD card and insert). There's no remote-kill like the Kindle.

If you're worried about finding DRM free content, check out Baen's Webscriptions or Fictionwise (look for the "multiformat" books; all DRM free).

Finally, if you REALLY don't want to go with Sony, there are lots of other good readers out there, some of which run Linux, and give you source for the software.

Or at least, it is compared to the Kindle. Sony will read PDF files and EPUB files. (EPUB is an open standard; an EPUB file is really a zip file, containing a few XML documents that describe where everything is, and then either XHTML or DAISY/DTBook content).

It's VERY easy to copy content to the Sony readers (shows up like a USB hard drive, or copy content to an SD card and insert). There's no remote-kill like the Kindle.

If you're worried about finding DRM free content, check out Baen's Webscriptions or Fictionwise (look for the "multiformat" books; all DRM free).

Finally, if you REALLY don't want to go with Sony, there are lots of other good readers out there, some of which run Linux, and give you source for the software.

"Also keep in mind that he is making, to quote, "well into six figures" on ebooks. While nobody else is making anything worth mentioning."

In an interview with Weekly Planet, Ellora's Cave is said to be selling 8000 books per week. I don't know how much of these are ebooks, and I don't know how much of the cover price goes to EC's profits.

Another article says: "In 2003, the company grossed over $1.2 million and paid over $500,000 in royalties." But again, I don't know how many of these are ebooks and how many pbooks.

Project Gutenberg has 2,000,000 downloads per month, but at $0 per download, so the profit is always $0. :-)

Also: "Publishers reported 484,933 eBook units sold and $3,182,499 in revenues for the second quarter of 2005. 14 publishers contributed to the Q2 2005 report including Elib AB; Ellora's Cave Publishing; Fictionwise, Inc.; Hard Shell Word Factory; HarperCollins; Houghton Mifflin Company; John Wiley & Sons, Inc.; McGraw-Hill Professional; Pearson Education; Random House; RosettaBooks LLC; Stonehouse Press; Time Warner Book Group and Zondervan."