Saturday, March 30, 2013

Using the @media query for Kindles

Amazon's new format, KF8, has added support for many features that the older mobi format was lacking. That's great, right? Well, KF8 is only supported on newer devices: the fourth generation of Kindles and newer.

But, I've heard from many authors that they don't want to limit their market. They want to sell their books on as many people as they can and I can certainly understand that.

So, what's the problem? The problem for me is, should I code the book for the older devices, or should I code it for newer devices?

The example I'm going to be using is tables since that's what I first experimented with.

Older Kindles had very limited support for tables. They supported simple tables, but they didn't look very great. So, the advice has generally been convert your tables to images and use that. That way you know your table will appear the way you want it to. On the other hand, the new KF8 format has much better support for tables. They also look and function much better.

If you code a table for a KF8 file, it won't look very good (or may display terribly) on older devices. But if you code a table for the older mobi format, you know that it could have been better on newer devices.

So, what to do?

Well, another new feature that came with KF8 was support for media queries. What does that mean? Basically you code for both versions in one file. The KF8 code will appear on devices that support it and the older code will appear on devices that don't.

I wrote up my experience when trying this for the first time as I was doing it. Here it is for anyone who would like to learn along with me:

So, first I build the book for KF8. That means building the tables in html. I like to do this separately at first. For example just open TextEdit/NotePad and write out the code for the table and fill it in. Once you're done with it you can copy/paste it into the book.


Ok, now that the book is all finished and formatted for KF8, it's time to go back and code in the table images that will (hopefully) appear on older devices.

So, here's what I've added to my stylesheet:

{ }
{ display: none; }

@media amzn-mobi
{ display: none; }
{ display: block;
margin-left: auto;

So, the "mobi" class should only display on devices using the old mobi format. And I didn't want to change any of the formatting I'd already done so I left the "kf8" class blank.

Any table I have in the document gets the class "kf8" and just below them I'm adding in the images and giving them the class of "mobi".

<table border="1" cellpadding="5" class="kf8">
<p><img class="mobi" src="../Images/filename.jpg" /></p>

I left off the mobi class first to make sure the images display properly. Add in the mobi and watch them disappear.

Now, do this to all the tables in the book.

Now to toss it into kindlegen and see what happens. *Fingers crossed*
It completed the book with no warnings, that's a good sign.

Now to test the file. First, I'll open it in Kindle for Mac and see how it looks. Other than forgetting a kf8 class on one of the tables it seems to have worked. Now to try it in Kindle Previewer... And it works. I'm kinda surprised it went that easily. The tables are displayed on the Paperwhite and Fire, and the images are displayed on the Kindle and DX. Now, a final test. Load the file onto my Kindle Touch (KF8 supported) to see how it looks.

The tables are looking very good.

A success!

Here's a sample from Amazon's Kindle Publishing Guidelines (slightly editted by me) that you can try out for yourself. Try it in sigil or your favorite eBook/HTML editor and learn how to apply it to your own work.

Here's what you would add to your stylesheet:

{ display: block; }
{ display: none; }
@media amzn-mobi
{ display: none; }
{ display: block; }

And here's the code that would appear in your book:

<table class="kf8" bordercolor="#E66C2C" border="1" cellpadding="4">
<th>Heading 1</th>
<th>Heading 2</th>
<th>Heading 3</th>
<td>Cell 1</td>
<table bordercolor="#003399" border="1" cellpadding="4">
<td>Nested 1</td>
<td>Nested 2</td>
<td>Nested 3</td>
<td>Nested 4</td>
<td>Cell 2</td>
<img class="mobi" src="../Images/tableimage.jpg" />

A final note:
I used tables as an example, but this is definitely not limited to that. You can use this for any coding that you want to appear differently on one device vs another.
Just apply the “KF8” class to what you want to appear on the devices that support the new format. And apple the “mobi” class to what you want to appear on older devices.

Sunday, March 24, 2013

Converting vs Formatting

It has never been so easy to publish your own book. And now eBooks are becoming more and more popular. There are multiple options for reading, or publishing, including (but not limited to) Amazon/Kindle, Barnes & Noble/Nook, Apple/iPad/iPod/iPhone, and various less well known mediums.

I know from my own personal experiences of purchasing eBooks that not all books are formatted well. Now, it varies from person to person, but those formatting errors can be minor annoyances or make a book completely unreadable.
It can be something minor. I've had a couple eBooks from big publishers that didn't have a working navigational table of contents. This meant that I couldn't 'flip' between chapters, and there were no chapters listed in the 'Go To' option.
Or it can be something major. I've seen eBooks that have spaces that take up have a screen, paragraphs that break in the middle of a sentence, or a complete lack of spacing so it's difficult to tell where one paragraph ends and the next one starts.

Of course, no one wants to have problems with their book. You've spent so much time and effort writing your book. You want other people to enjoy it. So, what do you do now? How do you ensure that your book looks nice, and works with whichever device you've decided to publish on? Maybe you've decided to format/convert the file yourself, or maybe you've decided to hire someone else to do it.

Now that brings up the question: What's the difference between formatting and converting an eBook?

In short, formatting requires much more time & work and ensures a good looking/functional final product, while converting is a quick automatic process (usually involving a conversion program) and the results can be unpredictable and may look slightly off or just wrong.

Formatting a document has to do with changing the way it looks and/or functions. Formatting eBooks requires knowledge of html and css. What does that mean? HTML is the basic structure of the eBook (paragraphs, chapter headings, images, etc) while css is the style of the book (fonts, sizes, spacing, colors, etc).

Basic formatting would include things like: first line indents, paragraph spacing, font sizes, text/image alignment, ensuring the eReader device "sees" the chapters, adding and linking a Table of Contents (if it's not already there), etc...

Converting a document is simply changing it from one file type to another. For example, you have a Word Doc and you use a program to convert it to mobi.

There are many free programs available that will convert your book between many different file types. They will not ensure that the book looks good, only that it has changed from one file type to another.

Now, I'm not saying that those conversion programs are bad. They can be very useful. Calibre, for example, is a very useful, free, conversion program. You can get fairly decent results, but only if you understand what all the options mean and how they apply to your book. In fact, if your Word doc is well formatted, and if the book is simple (mostly text), you can sometime use a converter program and get decent results.

Ah, but I just said 'well formatted', didn't I? Which leads me to...

In my opinion, it's not so easy to separate the two. At least, now when everything's properly done. A good eBook will look nice (formatting) and be in the file type you need (conversion). If you skip either of these processes your book won't work out very well. If you simply convert the book, your formatting will probably not be what you want. Just like a well formatted document won't mean much if it's not converted to the proper file type.

In the end, to get the eBook you want, you'll have to both format and convert your document. If you decide to do this yourself then take the time and effort and you'll be happier with the results. Or if you decide to hire someone to do this, make sure the person you hire will take the time to properly format your document before they convert it.

Friday, March 22, 2013


I am a freelance eBook editor/formatter/converter. I've converted my fair share of eBooks and have seen quite a bit of both good and bad formatting. I thought I would start this blog to help out self-publishing authors when they're ready to publish their eBook, as well as advertise my services.

I've added two pages you can view from the sidebar on the right. One page shows the services I offer and the prices I charge. The other shows a list of eBooks I have formatted so you can see my work.

The formats that I almost always work with are Word documents that need converting into either mobi (for Amazon/Kindle) or ePub (for Barnes & Noble, Apple, etc). Therefore, most of the advice that I'll give will refer to those formats.

The programs that I use most often include Microsoft Word, Sigil, Kindlegen, Kindle Previewer, and Calibre, just to list a few. So, again, most of the advice I'll give will refer to those programs.

If you have any questions, or if there's anything you'd like me to post about, simple leave a comment.