Posts Tagged ‘ebooks’

A practical guide to selling ebooks online

Sunday, December 2nd, 2012

"What’s Next?"

Since this is a question I get a lot from users at eBookBurn.com and the stock FAQ answer usually leads to even more questions, I thought I’d summarize the details here.

This guide assumes you do not have a literary agent or publisher and are embarking on a self publishing journey.

It also describes the steps I went through in posting my own ebook, "Hurricane Sandy: The Diet" for sale (and of course, I would be remiss not to mention that it’s also available on iTunes and Barnes & Noble as well).

What you’ll need

Amazon

Amazon Kindle Direct Publishing (KDP) is by far the largest marketplace and exercises the least editorial interference.

That’s both good and bad.

On the plus side you can write about almost anything, and it has the potential to reach hundreds of thousands or more readers (Amazon has never disclosed how many Kindles it has sold).

On the other hand, there is a ton of literary flotsam and jetsam that normally would never have seen the light of day otherwise, and your book will be competing for attention in that mix.


The KDP “Add Book” form is simple, and getting a book listed for sale is fairly quick, usually within a day or so.

While at Amazon, go ahead and create an affiliate account so that you can take an additional share of the sale if a buyer gets it by following a link from your web site, blog, twitter feed, etc.

If you’re unfamiliar with how affiliate programs work, read the help on Amazon’s site or this more general article at Wikipedia.

Apple

Apple’s iBookstore, which is part of iTunes, makes your book available to iPad and iPhone users, as well as people using Mac desktop or laptop computers.

Apple has some prerequisites of its own:

  • Get an Apple ID if you don’t already have one
  • Download iTunes Producer (as of this writing, the latest version is here)

Unlike the other sites which let you upload your epub file from any web browser, you must use iTunes Producer to deliver your book to the iBookstore, and since there are no versions for Windows or Linux, you must have access to a Mac OSX computer.

Apple is notoriously slow and capricious in its review process, and has been known to reject books for no good reason.2


One the plus side, the content in the iBookstore tends to be of better quality, and you can charge more for it.

Barnes & Noble

PubIt is Barnes & Nobles’ answer to Amazon’s KDP.

It seems the smallest of the three marketplaces, though it’s difficult to be sure: like Amazon, B&N has declined to say how many Nooks have been sold.

Functionally it is similar to KDP, and they too have an affiliate program (though it’s invite only, and it’s not clear if it’s worth the trouble at this point).

They are a little more complicated, though, in that immediately after creating an account they may send an email asking you to call them and verify information you provided through the web form with one of their employees.

That verification takes a few days, but once you are cleared, adding and editing books through its web form is easy, and changes take effect within one or two days.

Other ebook marketplaces

There are several of them out there, but none merit any attention.


The typical iPad, Kindle or Nook user is not going to look outside the built-in store for content, and the few technically-savvy ebook nerds who do are going to want content for free.


1 I’ve never understood the value of an ISBN: it provides no intellectual property or legal protection, and with other, free or non-profit initiatives to classify books such as the Library of Congress and Open Library, there’s no good reason to spend money to get one. Fortunately, none of the three marketplaces require it (perhaps they tacitly agree with my sentiment, but are not in a position to say so out loud).

2 Apple’s over-zealous editorializing has opened them up to sarcastic protests, and occasionally they get stung.

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 eBookBurn.com, 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="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" viewBox="0 0 592 900" preserveAspectRatio="xMidYMid meet">
<image width="592" height="900" xlink:href="images/page01.jpeg" />
</svg>

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; }
</style>

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="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100%" height="100%" viewBox="0 0 592 900" preserveAspectRatio="xMidYMid meet">
<image width="592" height="900" xlink:href="images/page01.jpeg" />
</svg>
</div>
</div>

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 BookHunch.com, 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 eBookBurn.com 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 eBookBurn.com, 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.

Object Orientation in C (without the ++)

Tuesday, July 29th, 2008

Professor Axel-Tobias Schreiner shows how to use object orientation with pure ANSI C.

His book “Object Oriented Programming with ANSI-C” was originally written in German, but he’s also made available a free downloadable pdf in English.