Friday, June 19, 2009

Worse is Better in eBook formats

Marshall T. Vandegrift has a great post about the four most popular eBook formats out there: eReader, LIT, Mobipocket, and ePub. The writing is a bit technical, but he deftly discusses the reasons why Mobipocket has taken the lead over eReader and LIT, and why it still has some value over ePub. Definitely a worthy read.

Labels: ,

Sunday, June 14, 2009

Kindle DX Image Test

In my book, Kindle Formatting: The Complete Guide, I cover a broad range of formatting information and tips, with examples of HTML code that can be effectively used in Kindle books to create the best display possible on the Kindle 1 and Kindle 2. I bought the new Kindle DX last week, and after some extensive testing I would like to share with you some information on the formatting differences between it and the other Kindle devices.

There are actually not too many formatting differences between the Kindle 2 and the Kindle DX. The basic paragraph formatting is the same, the text indents are the same, and the specialized formatting I discuss in my book for creating outlines and poetry all works the same. It does not appear that Amazon has made any changes to the default text formatting on the Kindle DX like they did on the Kindle 2.

The only change that will make a large impact on anyone developing books for the Kindle DX is the screen size and how images are displayed on the device. I discuss image dimensions on the K1 and K2 in Chapter 5 of my book:

There has been a lot of talk on the Kindle DTP forums about what dimensions an image should be to take full advantage of the available screen real estate. The consensus opinion, and the response stated by the DTP admin, has been that 450 pixels wide by 550 pixels high (a ratio of 9:11) is the proper scale. In the course of my formatting work and testing I have found that there is a little bit more to the story than that.

The actual size of the viewable book area on the Kindle 1 screen is 524px × 640px, and the viewable book area on the Kindle 2 screen is 520px × 622px. Any images larger or smaller than that (including those sized 450px × 550px) will be automatically re-sized until the width or height fits the viewable book area. At 261px × 319px on Kindle 1 and 260px × 311px on Kindle 2 (half the size of the viewable book area) the image is no longer resized to fit the book area’s width or height. This is important when you are creating logos or other small images for your book. Logos usually look great when sized around 75–100px wide. However, images will still lose some quality when reduced in size, especially photos. I suggest that you keep your images at the Kindle 2 dimensions (520px × 622px) if you can, so that your image quality does not suffer.

Since the Kindle devices all allow image zooming, you could also create images for the K1 and K2 that are 600px × 800px with the instruction that users click on them to zoom in and see the images full-screen. That is not practical in books that have a large number of images, but it would be useful for books with detailed maps or graphics that make a big difference to the content of the book.

DX screen testLike the K1 and K2, the Kindle DX has specific image dimension restrictions of which every eBook creator should be aware. The DX screen is 824 pixels wide by 1200 pixels high, and the viewable book area on the DX is 744px wide by 1022px high. The DX also has the same automatic up-scaling feature present in the K1 and K2, so all images larger than 372px × 511px will be automatically re-sized to fill the width or length of the viewable area. That applies equally to images made for K1 and K2 books, which are displayed on the DX with a noticeable decrease in image quality.

That leads me to my current frustration and to a very large problem with the current publication process at Amazon. The default format for books on all three Kindles is the Mobipocket eBook format. When you upload a Word document, PDF, or HTML file to the Digital Text Platform (DTP), the system runs Mobigen (the command-line version of Mobipocket Creator) on the file and generates a PRC/MOBI/AZW file that can be read on the Kindle. The same process is activated when you send a file to your Kindle using its e-mail address. Because the DTP will automatically create a Mobipocket file based on the file you upload, it is always best to create and upload a Mobipocket file yourself. In addition to giving you better control over and knowledge of the book's formatting, uploading a Mobi file gives you the ability to add a cover image that automatically zooms on the K2 and DX, and it gives you the ability to create waypoints in the Location Bar on those devices, making navigation between chapters as easy as a right- or left-click on the joystick. I cover the details of creating a Mobipocket file with these additional features in Chapter 7 of my book.

However, Mobipocket Creator and Mobigen both reduce the size (and, by necessity, the quality) of images when embedding them in a Mobipocket file. That function was apparently included in the days when Mobipocket books were being read on small Palm-like devices that could not handle large, high-quality images or large file sizes. Images that are the proper dimensions for the Kindle DX screen are automatically re-sized whenever you generate a Mobipocket file. This function cannot be overridden, and is not related to the compression option you can set in the two programs.

The only way I have found around this automatic re-sizing is to generate the Mobipocket file using the any2mobi command line tool provided with calibre. This tool does not re-size the images when it creates the Mobi file, so the quality of the images does not suffer. If you have calibre installed, calling the any2mobi command is very easy. You can run it on an HTML, OPF, or ePub file, or on a file in any of the other supported formats. You could even create your OPF file using Mobipocket Creator, then create the mobi file using any2mobi.

imgThe re-sizing error in Mobipocket Creator and Mobigen brings an important additional side effect into the picture. Because Amazon uses Mobigen behind-the-scenes to create practically all of the books that are for sale on the Kindle store, there are currently no books on the Kindle store that are actually developed specifically for the Kindle DX. In effect, the "Optimized for Kindle DX" icon we have seen cropping up lately is useless. I downloaded samples of many of these books to my DX and found that their images all suffer from the re-sizing/compression issue.

This issue also highlights the problem with selling one book file for use on every eBook device. While the goal of a universal eBook file is great, reality has not yet caught up with desire, even in the ePub ecosystem. Because every device is different, there is still a lot of value in giving users a file that is formatted specifically for their device. This is especially true of devices that have extraordinarily large or small screens, or devices that have display limitations. Amazon has a unique opportunity here to allow publishers and authors the ability to target book files at specific devices. What works well on the K2 may not work as well on the DX, and vice versa. Since Amazon knows what device a file is being sent to, they could set up the system to deliver an optimized book file for the device chosen. That would allow content providers to upload optimized books to the Amazon server with the intent of giving users the best possible reading experience. Whether Amazon adjusts the system to do that or not is up in the air, but I think it would go a long way toward increasing the real and perceived value of eBooks.

Another problem with the way the Kindle devices currently handle images is the automatic up-scaling of images larger than half the viewable screen width. This function creates a lot of confusion about the actual screen real estate available, and, by necessity, it makes small images grainy and pixelated. If you have to make a 200 pixel wide logo 100 pixels wide just to make sure it does not take up the whole screen on the Kindle 2, the logo is going to lose a lot of quality. The resolution of Kindle E Ink screen is 167 pixels per inch, much better than just about any computer monitor available. Images in Kindle books should be allowed to take advantage of that amazing resolution and to take up consistent space on the screen, giving content creators more flexibility in designing eBooks that look great and provide the best reader experience possible.

In conclusion, I sincerely hope that Amazon releases updated versions of Mobipocket Creator and Mobigen, and that they remedy the issues with optimized eBook files and image up-scaling. As always, I will be closely watching the Kindle format, and I will keep you up-to-date if anything changes.

Hat tip to John at Reader Plates for the calibre solution.

Labels: ,

Tuesday, April 28, 2009

eBook Reader Screens

There has been a lot of talk lately about eBook device screens, so I thought I would add my thoughts to the mix.

Stephen Windwalker wrote recently about the future of E Ink and what he expects we will see in versions of the Kindle coming in the next few years. He based his predictions on information from the makers of the e-paper screens and on the assumption that Amazon will stick with that technology indefinitely, and the predictions sound very plausible. My concern with that possible roadmap is that the "full-color" device Stephen mentions for 2011 will probably be quite anemic in actual color. The current color E Ink technology is limited to pastels, and from what I can tell will always look washed out and not true to the actual colors being displayed. The technology just seems flawed in that regard.

Note: As mentioned in the comments, I originally misread and misquoted Stephen in this post. After he graciously pointed that out to me, I have adjusted my previous thoughts. My sincerest apologies, Stephen.

The most interesting news recently is that PixelQi is developing a screen with three different settings: low-power black and white, e-paper, and full-color LCD. It sounds to me like this technology has some great value and will become a condender in the marketplace. Add to that Mike Cane's guess that PixelQi might be providing Apple with screens for its rumored tablet/eBook device, and we have some tantalizing reasons to stay up with the news.

However, I'd like to point out that three screen display modes is still that: different display modes. Just because I am outside do I have to stop seeing color? That might work well on an OLPC, but I like the best possible display on my devices.

That's where a little-known and seemingly ignored technology comes into play. I don't remember where I first heard of the Qualcomm mirasol display, but I am pretty sure it was not in relation to eBooks. The mirasol technology is reflective like E Ink, but it is full-color with faster-than-video refresh rates. Yes, you heard me right. We could have an eBook device that uses the same power consumption as the current ones, but with color and video. Where do I sign up?

The bummer is that the technology is still in development. Qualcomm has successfully deployed monochrome screens, but apparently making the full-color ones is more difficult.

I think the major players in the eBook market are barking up the wrong tree. E Ink is fine for basic devices, but I would much prefer the mirasol screen to a washed-out, pastel, slow-refresh E Ink screen that we might possibly have in two years.

Here is a sales video that might be interesting to the more sales or techie-oriented among us, and here are some interesting pictures of the full-color screen in different lighting situations.

Labels: ,

Wednesday, March 4, 2009

Kindle on the iPhone

Amazon has announced the availability of Kindle for the iPhone. This new iPhone and iPod Touch application has the ability to sync up with the books you have purchased on the Kindle via Whispersync, so you can continue reading when you don't have your Kindle around. I just wanted to make sure you all know about this great option that increases the sales opportunities for authors and publishers publishing on the Kindle. There are instructions in Amazon's help files.

Labels: ,

Wednesday, February 25, 2009

Kindle 2 Review, the Formatting Perspective

There have been a couple of really good Kindle 2 reviews in the last day or two, including Alexander Falk's, which I found to be a good overview of the changes and adjustments in the K2. What I am going to bring you now is a review of the formatting and book display changes that come to us in the new device, some of which are great and some of which are just going to cause frustration. I'm going to list them in no particular order.

Line height: The line height on the K2 has been reduced, allowing more text to show up on the screen. This equates to about 4 more lines of text on the screen at font size 3.


click for full-size

Font clarity and size: The new 16-level grayscale screen, in addition to making images clearer, has made the Kindle font (Caelicia) show up a bit better on the screen. That actually makes the font a little bit lighter, from what I can tell, but it does not make it significantly less readable. It does appear as you compare the two screens that the font on the Kindle 2 is just a tiny bit smaller than the same size font on the Kindle 1. I have compared the font sizes in screen shots, and it does not appear to actually be smaller. However, there are a few places where a size difference definitely does stand out, most noticeably the size of the bullets in unordered lists.

Indentation: On the Kindle 1 the first-line indentation for paragraphs is .25 inches and the left indentation for blockquotes and lists is in .5 inch increments. That allows three full indentation levels and part of a fourth before the text is too scrunched up and the indentation just stops happening. On the Kindle 2 the blockquote and list indentation has been reduced to .25 inches, allowing five full indents and part of a sixth before stopping.

Em units are smaller: On the Kindle 1, em-units (a measurement that equals the height of the font at the current size) are about twice as large as they should be, but on Kindle 2 they have been reduced to the correct size. On both devices the em-unit size does change properly with the user's font size adjustments.

Justification wrapping: The Kindle automatically fully justifies the text in books unless the creator explictly overwrides that setting. On the Kindle 2 there seems to be a bug that does not spread the text of a line out to the end if there is a certain amount of space already between the words. So, if a larger word wraps to a new line the text before it may not be flush with the right margin. This is apparently only a big issue at the larger font sizes, but it does show up periodically at the sizes 3 and below.

Broken Justification: This next one is a pretty important bug that I hope gets addressed soon. On the Kindle you can override the default first-line indentation on paragraphs by assigning a width="0" to the paragraph or by giving it a text-indent:0 CSS style. You can also use other numbers in those values to precisely manage the first-line indentation in the file.

The problem is that any time you use either of those commands the Kindle 2 will assign a left justification to the paragraph instead of retaining the default full justification. This bug poses a significant problem for formatting since no-indent paragraphs are used on a regular basis in books. For example, in many books the first paragraph under a heading is given a no-indent style. Unless the entire book is formatted in a left-aligned style, those paragraphs will stand out significantly.

It should also be noted that the option to turn on or off justification, which is available in the K1 with a hidden command in the font size menu, is not available in the K2, as far as I can tell.

Image Dimensions: The dimensions of the space available on the Kindle screen for book content (both text and images) has changed a bit with the new device. First, you should be aware that since the release of the Kindle 1 the typical answer on the DTP forums has been to make full-page images 450px by 550px. However, on the K1 the available screen area is actually 524px by 640px. Images smaller than that but larger than 261px by 319px will be upscaled to fill the screen area in width or height. This automatic adjustment can have a negative effect on the quality of the image, so it is best to size images at the actual dimensions of the available screen area.

On the K2, the available screen area is 520px by 622px. This is an odd size difference, but the best approach is to size images with the smaller K2 content area in mind.

HTML Tables: One of the biggest complaints about the K1 has been that it does not support tables. This complaint was made more pointed by the fact that tables are supported in Mobipocket, which is the foundational format of Kindle books. Well, the K2 displays tables, even handling them the same way Mobipocket does, by allowing the user to scroll the table horizontally when it is wider than the screen area.

Strikethrough: The K2 has a small change in the placement of the strikethrough line as seen in the image here.



Overall, the changes in the Kindle 2 seem to be aimed at making the text easier to read and easier on the eyes. The line height changes look good, and seem to handle superscripts and subscripts better. The justification issues will be annoying for formatting needs, but should be easy to fix with a firmware update. I really would love to see the Kindle 1 get table support, but unless or until that happens I will continue to use images. The 500,000 or so Kindle 1 users out there will appreciate that, I suspect.

Labels: ,

Monday, February 16, 2009

Greek text on the Kindle

As I mentioned in my last post, the Amazon team recently released a firmware update (version 1.2) that allows some much-needed functionality in Kindle books. I was finally able to test the Greek functionality and figured out how to add Greek text to HTML files destined for the Kindle.

First, add the Greek characters into the file using Unicode character entities. For instance, the lowercase alpha is α or α. You could also add the actual character (copied from character map or another source) but I do not suggest doing that since it is usually a better coding practice to use the entity. Also, it just makes inserting and messing with the characters easier.

After the characters are inserted, the file needs to be saved with a Unicode encoding. I suggest using UTF-8, a very common encoding that will be sufficient for these purposes. Just open the HTML file in your default text editor or in Notepad, go to the Save As dialog box, set the encoding to UTF-8, and save the file with the same name or a new one. That HTML file can now be used in Mobipocket Creator to create a PRC file for testing, or be sent to the Kindle through the automated conversion system.

As always, I do not suggest you try uploading Microsoft Word or PDF files, with or without these characters in them. The Kindle format is HTML, and you are always better off formatting and tweaking in that code.

Overall, the Greek support is pretty good on the Kindle. The only characters which are not supported are the archaic koppa, sampi, digamma, and stigma in uppercase and lowercase. The Kindle does support all of the other Greek characters, including all of the pre-composed characters with diacritics... and I mean all of them. I was not able to find any that are not covered. I have included some screenshots below that will give you a sampling of what the Greek looks like on the device, including in the mono-spaced font.

As always, if you have any questions or thoughts on this, please let me know!


Image 1
Image 2
Image 3
Image 4
Image 5
Image 6
Image 7
Image 8
Image 9

Labels: ,