Posts Tagged ‘E-Books’

The Forgotten E-Book Reader: OLPC

Monday, December 26th, 2011

With the plethora of e-book reader devices available these days, it’s easy to overlook perhaps one of the better choices for mobile e-reading: the OLPC.

While it’s a bit heavier than most tablets (but still relatively light at just over 3 pounds), and lacks the “instant-on” feature of other devices (the OLPC is technically a netbook computer, so it needs time to boot), the built-in Read Activity (app) supports several types of file formats, including text, tiff, djvu, pdf, and epub.

At 6 inches x 4.5 inches, the OLPC’s color screen is bigger than most dedicated e-book readers, and almost as large as the iPad. The screen folds flat, which hides the keyboard and makes reading easier, and the screen also remains easy to read, even in sunlight.

So why isn’t it more popular as an e-book reader?

One problem is that it’s not clear how to add new content for the Read app to find.

By default, the Read app can open e-book files in the Journal, but the documentation doesn’t fully explain how to copy new files into the Journal.

In theory, you can drag-and-drop files from a mounted usb stick or external drive, but I found the graphical environment choppy and unreliable.

Fortunately, there’s a built-in Terminal script called copy-to-journal created just for this purpose.

Here’s an example of how to copy a pdf file from a memory stick to the Journal:

copy-to-journal "/media/my-usb-stick/My Book.pdf" -m application/pdf -t "My Book"

The first parameter is the full path to the file (wrapping in quotes is good practice, since it will work for files with spaces in their names and without), the second parameter (-m) specifies the mimetype, and the third parameter (-t) defines the title of the book as it appears in the Journal (it can be completely different from the filename).

Epub files work the same way, except the mimetype is different:

copy-to-journal "/media/my-usb-stick/My Book.epub" -m application/epub+zip -t "My Book"

The script can also attempt to guess the mimetype, using the -g switch instead of -m:

copy-to-journal "/media/my-usb-stick/My Book.epub" -g -t "My Book"


Illustrated ebooks with epub: using the svg image element

Wednesday, June 15th, 2011

All things being equal, the epub format is preferable to pdf for reading on devices like the iPad, Nook, Sony, Kobo, and other dedicated e-readers.

But for some types of books (such as manga, comics, or graphic novels), epub doesn’t seem to be able to handle large images that should fill the screen.

Apple has gone so far as to create its own fixed layout format for such ebooks.

It is possible, though, to stick with epub and get perfect results for illustrated ebooks, using the forgotten (or perhaps simply overlooked) svg image element.

Here’s a peek under the hood of how we do it at, as part of our new illustrated ebook publishing feature.

This is an example of the markup to use in your epub’s xhtml files for each image:

<svg version="1.1" xmlns="" xmlns:xlink="" width="100%" height="100%" viewBox="0 0 592 900" preserveAspectRatio="xMidYMid meet">
<image width="592" height="900" xlink:href="images/page01.jpeg" />

What this markup does is take a JPEG image sized 592 pixels wide by 900 pixels tall, and frame it in the center of a 592×900 svg element.

It turns out that 592×900 is the right size and aspect ratio for “standard-sized” six inch e-ink screens found on the regular Nook, and Sony Reader.

So why use svg at all?

Wouldn’t it be simpler to define it with the plain img tag (as this epub template does), like this?

<img src="images/page01.jpeg" width="592" height="900" alt="Page 1"/>

Unfortunately, many devices, such as the iPad and the Nook Color, have screens larger than six inches.

So on those devices, using the plain img tag in your epub’s xhtml files leaves an embarrassing whitespace gap, from where the image stops to where the actual screen ends.

The svg element shown earlier, though, is different: it stretches the image to fill the entire screen, while preserving the aspect ratio.

It’s also important to note that 592 width and 900 height specified within the svg and image elements should not be thought of as pixel sizes, since no units are defined, but as a width-to-height ratio.

So any image with the same aspect ratio as 592×900 will work well, regardless of its actual size. Scaling up to larger screens, though, also means the dpi count should be reasonably high, at least 72 dpi (and more for images whose base size is smaller than 592×900 pixels).

For most devices, that’s enough, but some e-readers insist on adding margins and other padding to each page, so it’s helpful to define this in the xhtml file’s head block:

<style type="text/css">
@page { margin: 0.000000pt; padding: 0.000000pt; }

And these css classes in the stylesheet:

.svg_outer {
display: block;
margin-bottom: 0;
margin-left: 0;
margin-right: 0;
margin-top: 0;
padding-bottom: 0;
padding-left: 0;
padding-right: 0;
padding-top: 0;
text-align: left;

.svg_inner {
display: block;
text-align: center;

So the final xhtml for each page image looks like this:

<div class="svg_outer">
<div class="svg_inner">
<svg version="1.1" xmlns="" xmlns:xlink="" width="100%" height="100%" viewBox="0 0 592 900" preserveAspectRatio="xMidYMid meet">
<image width="592" height="900" xlink:href="images/page01.jpeg" />

Just repeat that pattern for every image in book, for every chapter that contains full-page illustrations.

Update, May 1, 2012: Moriah Jovan has been kind enough to provide sample epub files created using this technique:

Simplifying eBook Creation

Thursday, January 6th, 2011
If you are creating ebooks for sale, check out, a new approach to promoting books, regardless of whether you are selling your books on Amazon, iTunes, or elsewhere.

UPDATE, May 10, 2011:
The latest news about can be found here.

Last year, I presented a talk at BarCampNYC5 on "How to Create an eBook".

I spent most of the talk on ePub, and how to generate ePub files programmatically.

That audience was mostly developers or people otherwise technically-oriented, and while there were a decent amount of well-informed questions, it was clear that creating an ePub from scratch was a lot of work, with few good (read: simple) tools.

Even Adobe’s InDesign, which is used by most professionals, requires significant manual reworking.

Fast-forward to last month, when I released, an online eBook creator composed of Xinha on the frontend, fused with a more sophisticated version of the ePub generator described in the IBM tutorial.

I announced it on Hacker News, reddit, and MobileRead.

The initial response was terrific, and I even got an early review at the Digital Reader blog.

Over the past week, I got a chance to address common feedback with an update which I released today. Here were the major points:

  1. Pricing
  2. The first go-round on pricing was based on the idea that if you hire a consultant to prepare a specification-valid ePub (and validity is important, since you cannot sell in Apple’s iBookstore otherwise, for example), it will cost upwards of $500 per book. So, in that context, a create-all-the-books-you-want model for a given amount of time made sense.

    Many people felt that was too high for self-serve, though, and it was a good point: while I make an effort to answer support emails, there’s no guarantee that I’m able and willing to address every customization request.

    So the new pricing reflects that, and there’s also a three day initial period where use is free.

  3. Cover Image Sizing
  4. Until today, your book cover image had to be exactly 590 pixels wide by 750 pixels tall. Any variation got you rejected.

    Now, it’s more of a suggestion, since the new release simply scales your image to the right size automatically.

    This is important for a few reasons: it’s a better user experience, and the 590×750 size is based on current standards, which will change over time as device resolution improves, etc.

  5. Importing from existing docs
  6. In the first release, you had to type everything from scratch, or cut-and-paste from another document.

    While that option is still there, many people wanted to be able to upload a non-eBook format document, and have the conversion done automatically.

    PDF was by far the most requested, followed (weakly) by MS Word.

    Even though PDF is a notoriously difficult format to parse into text, I have been experimenting with using the PDFMiner API, so I thought to try it here, despite Yusuke Shinyama’s warning:

    PDF is evil. Although it is called a PDF “document”, it’s nothing like Word or HTML document. PDF is more like a graphic representation. PDF contents are just a bunch of instructions that tell how to place the stuff at each exact position on a display or paper. In most cases, it has no logical structure such as sentences or paragraphs and it cannot adapt itself when the paper size changes. PDFMiner attempts to reconstruct some of those structures by guessing from its positioning, but there’s nothing guaranteed to work. Ugly, I know.

    The results are decent (if I do say so myself), but a lot depends on what kinds of pdfs are uploaded: essays, whitepapers, and other mostly-text docs come out ok, with some editing needed. Brochures, slides, forms, and other works with more intricate visual formatting require much more editing.

    But in contrast to other conversion tools which simply take static jpeg or png snapshots of each page (I’m looking at you, calibre), the full text is parsed and returned as text, which means it can be edited.

    There’s still no support for uploading and converting MS Word documents, partially because of how few people asked for it (especially relative to PDF), but mostly because of the huge pain in the neck it is.

    In theory, importing from Word’s docx format should be trivial, since it’s xhtml under the hood, which is just what ePub requires, but Microsoft added a few surprises.

    One option is to ask people to save as filtered HTML first, before uploading, but it’s not the best solution, so I’ll be considering ways to address that.

    I’ve also noticed that cutting and pasting from Word docs, which is the only alternative in the meantime, introduces funky Microsoft-specific namespaces which break validation, so I need to come up with a solution for that as well.

Book Burning in the Age of E-Books

Tuesday, June 8th, 2010

Book Burning in the Age of E-Books