R. Scot Johns's Blog, page 9
January 22, 2013
Kindle Fixed Layout Functionality [UPDATED 1-22-13]
Before we dive into the next portion of the tutorial, I thought it would be useful to post the following chart which comprises Appendix A of the ebook. This information will be discussed thoroughly and referred to throughout the tutorial, so having it beforehand might be helpful (especially since the ebook isn't out yet). And since much of it will make no sense without some explanation, I will provide a short introductory breakdown here as well. This will get a little technical, and may well make no sense at first for some of you (if so, just skip it for now and refer back when necessary), but it will all become clear in time. First, the chart...
Function
Booktype
Kindle
3
Paper
white
Fire
(Gen1)
HD7
HD9
PC
app
Android
app
1 - Page-Spread
Comic
Children
None
N/A
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
2 - Letterbox Color
Comic
Children
None
White
White
White
White
White
White
White
White
White
Black
White
White
Black
White
White
Choice
Choice
Choice
White
White
White
3 - Virtual Panels
Comic
Children
None
No
No
No
Yes
No
Yes
No
No
No
Yes
No
No
No
No
No
No
No
No
Yes
No
No
4 - HTML Image Zoom
Comic
Children
None
"Yes"
"Yes"
"Yes"
"Yes"
"Yes"
"Yes"
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
No
No
No
Yes
Yes
5 - Cover Image Access
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
6 - Cover Doubling
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
7 - TOC Menu Link
Comic
Children
None
No
No
No
No
No
No
Yes
Yes
Yes
No
NONE
No
No
NONE
No
Yes
Yes
Yes
Yes
Yes
Yes
8 - Bookmarks
Comic
Children
None
No
No
No
Yes
Yes
Yes
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
Yes
No
Yes
9 - Live Text Functions
Comic
Children
None
No
No
No
No
No
No
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
No
No
Yes
10 - Hyperlinks
Comic
Children
None
No
No
No
No
No
No
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
11 - Font Embedding
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Each of the 11 rows features one functionality element in KF8 that I have tested on the devices and apps listed in the five columns to the right. These are (in order): the Kindle for PC desktop application, a first generation Kindle Fire, the new Kindle HD 7" and HD 8.9" devices, and the Kindle for Android app. Unfortunately, I do not have a second generation Kindle Fire to test, nor a Mac on which to test the Kindle for Mac desktop application. And, of course, as mentioned in the Introduction, fixed layout files cannot be tested in the Kindle for iOS/iPad app, since transferring them in any way I have attempted (Dropbox / DiskAid / Send To Kindle) actually breaks the file. I didn't bother testing these on my Paperwhite or Kindle 3 keyboard model, since comics and graphic novels on these devices are pointless, even though technically they now support the format [see Update below].
As mentioned previously, there are two official book types for Kindle fixed layouts, defined by the appropriately titled "booktype" metadata value in the OPF file (to be discussed in an upcoming section), these being "children" and "comic." But, of course, you can also enter "none" (or simply leave it out), making essentially a third practical booktype. Unlike all the other Amazon-specific metadata values, which determine functionality for a specific listed attribute (such as fixed-layout or orientation, for example), the "booktype" attribute effects a broad range of overall ebook functionality - none of which is detailed by Amazon in their documentation. Hence, this chart. In it, each of the listed functions has been tested with each of the three booktype values set.
In addition, each of the three was tested with the RegionMagnification set both to "true" and to "false," since Amazon states in the Kindle Publishing Guidelines (Section 5.7) that the new Virtual Panels feature (row 3) is reliant upon this setting. This does not prove to be the case, as thorough testing resulted in no change whatsoever in the Virtual Panels functionality with either setting on any device or app. This, of course, may change in future updates, and I will update the chart accordingly at that time. But I have made no note of this distinction in the chart at present, since there is none.
Also, I should point out that in every case changing the booktype made no difference to the functionality of the Kindle for PC app, which appears to simply ignore the setting.
I have entered bold text for the results that stand out as the exception to the rule in order to make the disparity more readily apparent at a glance, and to point out issues with the functionality.
In addition, Appendix A provides no test results for region magnification features (aside from the new Virtual Panels function), as this is contained in Appendix B, and will be dealt with in the latter, more complex portions of the tutorial.
And now the breakdown...
1. Page Spread
A new function in KF8 is the "page-id" spine element which (purportedly) allows for the creation of two-page spreads in landscape mode (either with or without a margin in between). As you can see from the chart, this is only consistently true for the HD 8.9" ('HD9') device, while the HD7 and Android app work correctly with the "comic" booktype value only. In all other cases only one page is shown at a time in landscape mode. Even the Kindle for PC app, which shows an activated two-page button icon, does not actually display two page spreads.
2. Letterbox Color
This refers to the color used to fill in any display space outside the page area, much like the "letterboxing" used in widescreen movies on a 4:3 format television (or iPad). I only tested this because I noticed it was sometimes black and sometimes white and wasn't really paying attention at first to when and where. As it turns out it's only black on the two new HD devices with the "comic" booktype chosen, and white at all other times, with the sole exception of Kindle for PC, where the three standard values of white, sepia, or black are all still available. Not critical, but sometimes one or the other blends better, so it is interesting to know. And given that it is the newest of the Kindle line that sport the black background, this may be an indication of future changes.
3. Virtual Panels
This new feature is apparently a fallback for fixed layout ebooks that have no custom region magnification elements included, and works by dividing the page into four equal quadrants (or "panels") that are zoomed by tapping and advanced in sequential order by swiping (the ordering being based on the "primary-writing-mode" value to allow for right-to-left and left-to-right reading order). Surprisingly, the zoomed page can also then be scrolled around by dragging, and variably resized using pinch-and-zoom, making it a very nice add-on feature for most fixed layout ebooks (in the absence of precisely placed mag zones, that is). As already mentioned, it is supposedly activated by default when the RegionMagnification value is "false," but this value actually has no effect at present: Virtual Panels either work in a particular Kindle reader or their don't, and in most cases they don't. In fact, in only two instances does this currently work: on the HD7 and Kindle for Android app, and only when the booktype is set to "comic." My guess is this feature will continue to roll out until all Kindle iterations have it - aside, perhaps, from the HD9, which somewhat surprisingly doesn't have it; but, then, it doesn't really need it, either, due to its size. However, as you'll see in the next item, you can actually zoom images on the HD9 in certain instances.
4. HTML Image Zoom
This ties in somewhat with the last item, since only one or the other can work. This relates to the HTML <img src="http://feedproxy.google.com/~r/TheAdv... insertion method for adding background images in fixed layout, as opposed to the <div id="...> method of referencing a CSS background-image url. Amazon recommends the latter, but for reasons I will discuss later, I disagree (in fact, Section 4.2.3 of the Guidelines says it's a requirement, because "HTML images interfere with Region Magnification," which is demonstrably untrue). The important factor here, however, is that the <img src="http://feedproxy.google.com/~r/TheAdv... method allows the user to zoom a background image by double-tapping on it anywhere that it's not overlaid by text or Tap Targets, while the CSS method does not. This allows for zooming and scrolling entire background images (minus any text overlays), which until Virtual Panels was the only way this could be done. However, since the Virtual Panels function effectively creates a Tap Target covering the entire page, where that feature is active this one cannot be, since the background image cannot be tapped (the images still appear correctly using the HTML insertion method, so there's no issue where the image's placement is concerned). That said, assuming the RegionMag "true/false" value will eventually work as stated, you will then be able to chose one or the other, so this information will still theoretically be relevant. As seen in the chart, however, it's not just the Virtual Panels factor that determines whether <Img Src> Zoom works or not, since in no case does it work with the "comic" booktype value chosen. But since this is - at present - the only place where Virtual Panels works, in all other case (aside from Kindle for PC) this image zoom method works. An important distinction to make between Virtual Panels and the HTML "img src" method is that that latter only magnifies the actual background image (which is sometimes desirable and sometimes not), while Virtual Panels zooms the entire page, including text overlays, making it more like the iPad's pinch and zoom feature than Kindle's standard Panel View. (For an additional difficulty with Virtual Panels, see number 10. Hyperlinks below.)
5. Cover Image Access
6. HTML Cover Doubling
These two go hand-in-hand, and it all really comes down to one thing: Amazon flat out got it wrong on this one. In Sections 4.2.4 and 4.3.7 of the Kindle Publishing Guidelines Amazon either "requires" or "recommends" (depending on the section) than an HTML page containing the cover image be included in fixed layout files, even though in Section 3.2.3 they unequivocally state that you are not to do this because the cover image may appear twice - which is, in fact, exactly what happens in every instance. They then contradict themselves further by providing (in Section 3.2.3) one exception to this rule, in which case you must enter the linear="no" value to the spine entry for this element (the underlined element being "mandatory"); but then in the later two sections they state that the same value must be set to "yes." All this contradictory information can be cleared away easily by the facts: if an HTML cover is included, the cover image always appears twice. "Cover Image Access" simply refers to whether you can swipe back to the cover once you have moved forward into the book, and was tested in conjunction with the cover doubling issue to see how pervasive the latter was. In only one instance are you not able to return to the cover (even the HTML one) by swiping (or tapping), which is on the HD7. You can still access the cover via the menu link on this device, when again you will be presented with two consecutive covers, one JPEG, one HTML, but you cannot swipe back to it once into the book, whereas on every other device or app you can do so, and there will always be two consecutive cover images in a row. Moreover (and more importantly), including an HTML cover overrides the "start" Guide value for the "Go To Beginning" menu link, which will always go to the cover when an HTML cover is included, regardless of the "start" value given in the Guide, and even though there is already a cover link in the menu that renders this unnecessary and redundant. Without the HTML cover, you can use the "start" tag to point the "Beginning" menu link anywhere you like, and only one cover image will appear in your book. Therefore, there is simply no reason whatsoever to ever include an HTML cover, and several good reasons not to.
[UPDATE: 1/22/13 - The new HD 8.9" Kindle no longer recognizes the Guide "start" attribute when an active Table of Contents is present, but instead seems to always begin at the first page after the TOC, regardless of where the "start" value points. When no active TOC is present the "start" link functions correctly. Conversely, on the HD7" Kindle the "start" Guide item is ignored completely and the ebook will always open to the cover image, whether or not an active Table of Contents is included.]
7. TOC Menu Link
Since we're on the subject of menu links, here's another issue to consider. For some unfathomable reason, Amazon has decided to remove the "Table of Contents" link from the default "Go To" menu on the new HD devices. And not only that, but on ebooks with the "children" booktype value the entire "Go To" menu is inexplicably missing. Gone. Completely absent. No links to the cover, the beginning, or any other internal links. Apparently they think readers of children's ebooks don't use menus, nor that comics should ever have a Table of Contents - which, granted, they often don't, but lengthy graphic novels could certainly benefit from one. Perhaps they thought removing it was better than including a Go To menu where all the links are non-functional, but even so, removing the option is a bit reactionary, especially considering that the menu is still present and fully functional in all other Kindle readers.
8. Bookmarks
9. Live Text Functions (inc. Notes, Highlights, Search, & Definitions)
Of all the ebook functions that should never be disabled, these are the ones. If any feature promotes digital reading over print it's the ability to interact in highly useful and informative ways with the text. Being able to annotate, highlight (without ruining the book!), instantly search the entire text, and get the meaning of any word with just a tap of your finger - not to mention adding as many bookmarks as you like - are just some of the wonders that set ebooks apart. And yet Amazon has somehow decided (intentionally or inadvertently) that these features are not needed in children's books or comics. For with either of those booktypes entered they are all disabled - with the single exception of bookmarks in "comics" on the Android app. And mind you, this is not a fixed layout issue, not some odd quirk in the fixed layout Kindle code, since when you delete the booktype value altogether (or enter "none") all this functionality is back, with the fixed layout intact. It did not used to be this way for the "children" booktype, which originally retained live text functions, although "comic" did not have them from the very first. However, disabling them for children's ebooks only happened recently. I have ranted long and often on this here before, so I won't go on at length now. To me, there is simply no justification for this decision, since decision it must be, as there is no logical reason why a manufactured metadata value would have any effect it was not designed to have, unless Amazon is just not paying attention, which I find unlikely.
10. Hyperlinks
Somewhat similar to the live text problem is the issue of interactive links, both internal and external. Here there is fortunately only one disparity, which is on the HD7, where the "comic" booktype completely disables all text hyperlinks, none of which work at all. External hyperlinks are still blue, but non-active. This is clearly related to the Virtual Panels feature, rather than live text functions, since in all but this one instance hyperlinks work correctly even where live text is disabled. But as Virtual Panels currently only work on the HD7 and the Android app, it is possible that this feature is somehow interfering with the links, since Virtual Panels overlay the entire page with a tap target. However, given that the Android app is not effected, it's uncertain what is actually causing this. My concern is that as the Virtual Panels function is rolled out across devices the loss of hyperlinks might become a widespread problem. Hopefully the HD7 issue is an aberration, but it's 50/50 at the moment, so we'll just have to wait and see. Fortunately in most cases this is not an issue at present (which is little comfort to owners of a brand new HD7).
11. Font Embedding
This was just a standard test that I'm happy to report has essentially become unnecessary, as font embedding is now supported by all tested Kindle devices and apps. This was not the case just a few short years ago, when Kindle reflowable files did not allow custom fonts. Now they do, and KF8 has supported them from inception, and happily continues to do so. I include it because it's just good to know. And it's always nice to end on a positive note.
CONCLUSION
These are all considerations each ebook designer must weigh and make decisions on, based on their project and target audience. Bear in mind that digital publishing is still in its infancy, and in a state of great upheaval at the moment. All of this will settle out in time, but for now we have to be aware of what is possible and what is not, and try to stay abreast of any changes (which are numerous and often). Already this chart shows the great disparity between a single year's development of the Kindle Fire line: in at least half the features listed there is a difference in functionality between the 1st generation Fire and the latest models.
My biggest issue continues to be the lack of support for live text when either booktype value is entered, making my clear recommendation not to add one. The only functionality that will be lost by doing this are the two instances where Page Spread works with the comic value entered, but not when it is absent - these being the HD7 and Android app - as well as Virtual Panels on the same two readers. But since these features are hardly universal, being not yet present in any other case (aside from the HD9 where Page Spread is functional regardless of booktype), there is very little incentive to add a booktype value. The primary exception, unfortunately, is that only the "comic" booktype allows images of up to 800kb in size; otherwise, you're restricted to 256kb for fixed layouts, which can be a significant consideration with the advent of HD displays. Of course, this may all change (and probably will) over time as new updates are rolled out. But one cannot plan current work based on future possibilities. One must take what data is available today and use it to inform your present efforts.
As mentioned, I will update this chart regularly, and note the changes made at the bottom of the post. If a large number of changes are suddenly made - say, when a new line of devices arrives - I will do a new post and reevaluate the situation.
And by the way, if anyone has a 2nd generation Fire or a Mac with the Kindle desktop app and can test any of these features I would very much appreciate the information. I would love to add it to the chart for reference and will gladly give you ample credit and provide a link, both here and in the published ebook. For that matter, if any of your own testing contradicts what I have listed here, please let me know so I can look into it further. Comment below or send an email to scot(at)fantasycastlebooks.com.
UPDATE 1/6/2013
Just for the sake of being thorough, I went ahead and tested the eInk Kindle 3 and Paperwhite devices. And while I won't bother to include the data in the chart above due to space restrictions, I will point out the primary data points here.
First, and most surprising, is that the Paperwhite actually supports Page-Spread in all booktypes. This is accessed via the menu's "View in Landscape" option, since the Paperwhite has no internal orientation sensor. Just as interesting is the fact that, while the Kindle 3 does not support Page-Spread, it does default to landscape orientation for the booktype values "children" and "none" (though inexplicably showing only one page at a time), while for comics it reverts to portrait orientation. There is no way to change the orientation from the Kindle 3 menu. Letterbox color is white in each instance.
Equally surprising is support for Virtual Panels on the Paperwhite with "comic" or "none" booktypes (but not for children's books). This is, therefore, the only device that currently does so with the booktype absent, and only the second device that supports it at all. Why the eInk Paperwhite would support this function, but not the 1st gen Fire is beyond me (except that the Fire's OS has not been updated for some time).
Another curious fact is that pinch and zoom is available for all pages on the Paperwhite with any booktype setting, regardless of image insertion method. The Kindle 3 has some default zoom functions available via the menu, with incremental 5-way controller scrolling in all directions rather than the Virtual Panels' default quarter page progression. So that's a sort of "qualified" yes for that feature.
Cover issues remain consistent on both devices, and there are no Table of Contents menus in any instance. Bookmarks are functional in all three booktypes on the Paperwhite, but not at all on the Kindle 3, even though it retains the default Bookmark and TOC menu links, they're just grayed out and inactive. There are no live text functions, nor active hyperlinks, on either device in any booktype, but font embedding is consistently present.
UPDATE 1/15/2013
The chart has been updated to incorporate the tests I ran on the Kindle eInk devices for ease of reference and comparison. This makes the text in the table somewhat smaller that I'd like, but this is a restriction of the blog format. You can easily use the zoom function on your monitor to increase the text size for better readability, or - since it's a live table and not an embedded image - copy and paste it into a word processor and increase the font size.
UPDATE 1/22/2013
Section 5/6 on Cover images has been updated with a note regarding the "start" attribute in the OPF Guide section. This is only tangentially related to cover images, but the discussion of the Guide functionality in that section made it seem the logical place to include this info.
Function
Booktype
Kindle
3
Paper
white
Fire
(Gen1)
HD7
HD9
PC
app
Android
app
1 - Page-Spread
Comic
Children
None
N/A
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
2 - Letterbox Color
Comic
Children
None
White
White
White
White
White
White
White
White
White
Black
White
White
Black
White
White
Choice
Choice
Choice
White
White
White
3 - Virtual Panels
Comic
Children
None
No
No
No
Yes
No
Yes
No
No
No
Yes
No
No
No
No
No
No
No
No
Yes
No
No
4 - HTML Image Zoom
Comic
Children
None
"Yes"
"Yes"
"Yes"
"Yes"
"Yes"
"Yes"
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
No
No
No
Yes
Yes
5 - Cover Image Access
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
6 - Cover Doubling
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
7 - TOC Menu Link
Comic
Children
None
No
No
No
No
No
No
Yes
Yes
Yes
No
NONE
No
No
NONE
No
Yes
Yes
Yes
Yes
Yes
Yes
8 - Bookmarks
Comic
Children
None
No
No
No
Yes
Yes
Yes
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
Yes
No
Yes
9 - Live Text Functions
Comic
Children
None
No
No
No
No
No
No
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
No
No
Yes
10 - Hyperlinks
Comic
Children
None
No
No
No
No
No
No
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
11 - Font Embedding
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Each of the 11 rows features one functionality element in KF8 that I have tested on the devices and apps listed in the five columns to the right. These are (in order): the Kindle for PC desktop application, a first generation Kindle Fire, the new Kindle HD 7" and HD 8.9" devices, and the Kindle for Android app. Unfortunately, I do not have a second generation Kindle Fire to test, nor a Mac on which to test the Kindle for Mac desktop application. And, of course, as mentioned in the Introduction, fixed layout files cannot be tested in the Kindle for iOS/iPad app, since transferring them in any way I have attempted (Dropbox / DiskAid / Send To Kindle) actually breaks the file. I didn't bother testing these on my Paperwhite or Kindle 3 keyboard model, since comics and graphic novels on these devices are pointless, even though technically they now support the format [see Update below].
As mentioned previously, there are two official book types for Kindle fixed layouts, defined by the appropriately titled "booktype" metadata value in the OPF file (to be discussed in an upcoming section), these being "children" and "comic." But, of course, you can also enter "none" (or simply leave it out), making essentially a third practical booktype. Unlike all the other Amazon-specific metadata values, which determine functionality for a specific listed attribute (such as fixed-layout or orientation, for example), the "booktype" attribute effects a broad range of overall ebook functionality - none of which is detailed by Amazon in their documentation. Hence, this chart. In it, each of the listed functions has been tested with each of the three booktype values set.
In addition, each of the three was tested with the RegionMagnification set both to "true" and to "false," since Amazon states in the Kindle Publishing Guidelines (Section 5.7) that the new Virtual Panels feature (row 3) is reliant upon this setting. This does not prove to be the case, as thorough testing resulted in no change whatsoever in the Virtual Panels functionality with either setting on any device or app. This, of course, may change in future updates, and I will update the chart accordingly at that time. But I have made no note of this distinction in the chart at present, since there is none.
Also, I should point out that in every case changing the booktype made no difference to the functionality of the Kindle for PC app, which appears to simply ignore the setting.
I have entered bold text for the results that stand out as the exception to the rule in order to make the disparity more readily apparent at a glance, and to point out issues with the functionality.
In addition, Appendix A provides no test results for region magnification features (aside from the new Virtual Panels function), as this is contained in Appendix B, and will be dealt with in the latter, more complex portions of the tutorial.
And now the breakdown...
1. Page Spread
A new function in KF8 is the "page-id" spine element which (purportedly) allows for the creation of two-page spreads in landscape mode (either with or without a margin in between). As you can see from the chart, this is only consistently true for the HD 8.9" ('HD9') device, while the HD7 and Android app work correctly with the "comic" booktype value only. In all other cases only one page is shown at a time in landscape mode. Even the Kindle for PC app, which shows an activated two-page button icon, does not actually display two page spreads.
2. Letterbox Color
This refers to the color used to fill in any display space outside the page area, much like the "letterboxing" used in widescreen movies on a 4:3 format television (or iPad). I only tested this because I noticed it was sometimes black and sometimes white and wasn't really paying attention at first to when and where. As it turns out it's only black on the two new HD devices with the "comic" booktype chosen, and white at all other times, with the sole exception of Kindle for PC, where the three standard values of white, sepia, or black are all still available. Not critical, but sometimes one or the other blends better, so it is interesting to know. And given that it is the newest of the Kindle line that sport the black background, this may be an indication of future changes.
3. Virtual Panels
This new feature is apparently a fallback for fixed layout ebooks that have no custom region magnification elements included, and works by dividing the page into four equal quadrants (or "panels") that are zoomed by tapping and advanced in sequential order by swiping (the ordering being based on the "primary-writing-mode" value to allow for right-to-left and left-to-right reading order). Surprisingly, the zoomed page can also then be scrolled around by dragging, and variably resized using pinch-and-zoom, making it a very nice add-on feature for most fixed layout ebooks (in the absence of precisely placed mag zones, that is). As already mentioned, it is supposedly activated by default when the RegionMagnification value is "false," but this value actually has no effect at present: Virtual Panels either work in a particular Kindle reader or their don't, and in most cases they don't. In fact, in only two instances does this currently work: on the HD7 and Kindle for Android app, and only when the booktype is set to "comic." My guess is this feature will continue to roll out until all Kindle iterations have it - aside, perhaps, from the HD9, which somewhat surprisingly doesn't have it; but, then, it doesn't really need it, either, due to its size. However, as you'll see in the next item, you can actually zoom images on the HD9 in certain instances.
4. HTML Image Zoom
This ties in somewhat with the last item, since only one or the other can work. This relates to the HTML <img src="http://feedproxy.google.com/~r/TheAdv... insertion method for adding background images in fixed layout, as opposed to the <div id="...> method of referencing a CSS background-image url. Amazon recommends the latter, but for reasons I will discuss later, I disagree (in fact, Section 4.2.3 of the Guidelines says it's a requirement, because "HTML images interfere with Region Magnification," which is demonstrably untrue). The important factor here, however, is that the <img src="http://feedproxy.google.com/~r/TheAdv... method allows the user to zoom a background image by double-tapping on it anywhere that it's not overlaid by text or Tap Targets, while the CSS method does not. This allows for zooming and scrolling entire background images (minus any text overlays), which until Virtual Panels was the only way this could be done. However, since the Virtual Panels function effectively creates a Tap Target covering the entire page, where that feature is active this one cannot be, since the background image cannot be tapped (the images still appear correctly using the HTML insertion method, so there's no issue where the image's placement is concerned). That said, assuming the RegionMag "true/false" value will eventually work as stated, you will then be able to chose one or the other, so this information will still theoretically be relevant. As seen in the chart, however, it's not just the Virtual Panels factor that determines whether <Img Src> Zoom works or not, since in no case does it work with the "comic" booktype value chosen. But since this is - at present - the only place where Virtual Panels works, in all other case (aside from Kindle for PC) this image zoom method works. An important distinction to make between Virtual Panels and the HTML "img src" method is that that latter only magnifies the actual background image (which is sometimes desirable and sometimes not), while Virtual Panels zooms the entire page, including text overlays, making it more like the iPad's pinch and zoom feature than Kindle's standard Panel View. (For an additional difficulty with Virtual Panels, see number 10. Hyperlinks below.)
5. Cover Image Access
6. HTML Cover Doubling
These two go hand-in-hand, and it all really comes down to one thing: Amazon flat out got it wrong on this one. In Sections 4.2.4 and 4.3.7 of the Kindle Publishing Guidelines Amazon either "requires" or "recommends" (depending on the section) than an HTML page containing the cover image be included in fixed layout files, even though in Section 3.2.3 they unequivocally state that you are not to do this because the cover image may appear twice - which is, in fact, exactly what happens in every instance. They then contradict themselves further by providing (in Section 3.2.3) one exception to this rule, in which case you must enter the linear="no" value to the spine entry for this element (the underlined element being "mandatory"); but then in the later two sections they state that the same value must be set to "yes." All this contradictory information can be cleared away easily by the facts: if an HTML cover is included, the cover image always appears twice. "Cover Image Access" simply refers to whether you can swipe back to the cover once you have moved forward into the book, and was tested in conjunction with the cover doubling issue to see how pervasive the latter was. In only one instance are you not able to return to the cover (even the HTML one) by swiping (or tapping), which is on the HD7. You can still access the cover via the menu link on this device, when again you will be presented with two consecutive covers, one JPEG, one HTML, but you cannot swipe back to it once into the book, whereas on every other device or app you can do so, and there will always be two consecutive cover images in a row. Moreover (and more importantly), including an HTML cover overrides the "start" Guide value for the "Go To Beginning" menu link, which will always go to the cover when an HTML cover is included, regardless of the "start" value given in the Guide, and even though there is already a cover link in the menu that renders this unnecessary and redundant. Without the HTML cover, you can use the "start" tag to point the "Beginning" menu link anywhere you like, and only one cover image will appear in your book. Therefore, there is simply no reason whatsoever to ever include an HTML cover, and several good reasons not to.
[UPDATE: 1/22/13 - The new HD 8.9" Kindle no longer recognizes the Guide "start" attribute when an active Table of Contents is present, but instead seems to always begin at the first page after the TOC, regardless of where the "start" value points. When no active TOC is present the "start" link functions correctly. Conversely, on the HD7" Kindle the "start" Guide item is ignored completely and the ebook will always open to the cover image, whether or not an active Table of Contents is included.]
7. TOC Menu Link
Since we're on the subject of menu links, here's another issue to consider. For some unfathomable reason, Amazon has decided to remove the "Table of Contents" link from the default "Go To" menu on the new HD devices. And not only that, but on ebooks with the "children" booktype value the entire "Go To" menu is inexplicably missing. Gone. Completely absent. No links to the cover, the beginning, or any other internal links. Apparently they think readers of children's ebooks don't use menus, nor that comics should ever have a Table of Contents - which, granted, they often don't, but lengthy graphic novels could certainly benefit from one. Perhaps they thought removing it was better than including a Go To menu where all the links are non-functional, but even so, removing the option is a bit reactionary, especially considering that the menu is still present and fully functional in all other Kindle readers.
8. Bookmarks
9. Live Text Functions (inc. Notes, Highlights, Search, & Definitions)
Of all the ebook functions that should never be disabled, these are the ones. If any feature promotes digital reading over print it's the ability to interact in highly useful and informative ways with the text. Being able to annotate, highlight (without ruining the book!), instantly search the entire text, and get the meaning of any word with just a tap of your finger - not to mention adding as many bookmarks as you like - are just some of the wonders that set ebooks apart. And yet Amazon has somehow decided (intentionally or inadvertently) that these features are not needed in children's books or comics. For with either of those booktypes entered they are all disabled - with the single exception of bookmarks in "comics" on the Android app. And mind you, this is not a fixed layout issue, not some odd quirk in the fixed layout Kindle code, since when you delete the booktype value altogether (or enter "none") all this functionality is back, with the fixed layout intact. It did not used to be this way for the "children" booktype, which originally retained live text functions, although "comic" did not have them from the very first. However, disabling them for children's ebooks only happened recently. I have ranted long and often on this here before, so I won't go on at length now. To me, there is simply no justification for this decision, since decision it must be, as there is no logical reason why a manufactured metadata value would have any effect it was not designed to have, unless Amazon is just not paying attention, which I find unlikely.
10. Hyperlinks
Somewhat similar to the live text problem is the issue of interactive links, both internal and external. Here there is fortunately only one disparity, which is on the HD7, where the "comic" booktype completely disables all text hyperlinks, none of which work at all. External hyperlinks are still blue, but non-active. This is clearly related to the Virtual Panels feature, rather than live text functions, since in all but this one instance hyperlinks work correctly even where live text is disabled. But as Virtual Panels currently only work on the HD7 and the Android app, it is possible that this feature is somehow interfering with the links, since Virtual Panels overlay the entire page with a tap target. However, given that the Android app is not effected, it's uncertain what is actually causing this. My concern is that as the Virtual Panels function is rolled out across devices the loss of hyperlinks might become a widespread problem. Hopefully the HD7 issue is an aberration, but it's 50/50 at the moment, so we'll just have to wait and see. Fortunately in most cases this is not an issue at present (which is little comfort to owners of a brand new HD7).
11. Font Embedding
This was just a standard test that I'm happy to report has essentially become unnecessary, as font embedding is now supported by all tested Kindle devices and apps. This was not the case just a few short years ago, when Kindle reflowable files did not allow custom fonts. Now they do, and KF8 has supported them from inception, and happily continues to do so. I include it because it's just good to know. And it's always nice to end on a positive note.
CONCLUSION
These are all considerations each ebook designer must weigh and make decisions on, based on their project and target audience. Bear in mind that digital publishing is still in its infancy, and in a state of great upheaval at the moment. All of this will settle out in time, but for now we have to be aware of what is possible and what is not, and try to stay abreast of any changes (which are numerous and often). Already this chart shows the great disparity between a single year's development of the Kindle Fire line: in at least half the features listed there is a difference in functionality between the 1st generation Fire and the latest models.
My biggest issue continues to be the lack of support for live text when either booktype value is entered, making my clear recommendation not to add one. The only functionality that will be lost by doing this are the two instances where Page Spread works with the comic value entered, but not when it is absent - these being the HD7 and Android app - as well as Virtual Panels on the same two readers. But since these features are hardly universal, being not yet present in any other case (aside from the HD9 where Page Spread is functional regardless of booktype), there is very little incentive to add a booktype value. The primary exception, unfortunately, is that only the "comic" booktype allows images of up to 800kb in size; otherwise, you're restricted to 256kb for fixed layouts, which can be a significant consideration with the advent of HD displays. Of course, this may all change (and probably will) over time as new updates are rolled out. But one cannot plan current work based on future possibilities. One must take what data is available today and use it to inform your present efforts.
As mentioned, I will update this chart regularly, and note the changes made at the bottom of the post. If a large number of changes are suddenly made - say, when a new line of devices arrives - I will do a new post and reevaluate the situation.
And by the way, if anyone has a 2nd generation Fire or a Mac with the Kindle desktop app and can test any of these features I would very much appreciate the information. I would love to add it to the chart for reference and will gladly give you ample credit and provide a link, both here and in the published ebook. For that matter, if any of your own testing contradicts what I have listed here, please let me know so I can look into it further. Comment below or send an email to scot(at)fantasycastlebooks.com.
UPDATE 1/6/2013
Just for the sake of being thorough, I went ahead and tested the eInk Kindle 3 and Paperwhite devices. And while I won't bother to include the data in the chart above due to space restrictions, I will point out the primary data points here.
First, and most surprising, is that the Paperwhite actually supports Page-Spread in all booktypes. This is accessed via the menu's "View in Landscape" option, since the Paperwhite has no internal orientation sensor. Just as interesting is the fact that, while the Kindle 3 does not support Page-Spread, it does default to landscape orientation for the booktype values "children" and "none" (though inexplicably showing only one page at a time), while for comics it reverts to portrait orientation. There is no way to change the orientation from the Kindle 3 menu. Letterbox color is white in each instance.
Equally surprising is support for Virtual Panels on the Paperwhite with "comic" or "none" booktypes (but not for children's books). This is, therefore, the only device that currently does so with the booktype absent, and only the second device that supports it at all. Why the eInk Paperwhite would support this function, but not the 1st gen Fire is beyond me (except that the Fire's OS has not been updated for some time).
Another curious fact is that pinch and zoom is available for all pages on the Paperwhite with any booktype setting, regardless of image insertion method. The Kindle 3 has some default zoom functions available via the menu, with incremental 5-way controller scrolling in all directions rather than the Virtual Panels' default quarter page progression. So that's a sort of "qualified" yes for that feature.
Cover issues remain consistent on both devices, and there are no Table of Contents menus in any instance. Bookmarks are functional in all three booktypes on the Paperwhite, but not at all on the Kindle 3, even though it retains the default Bookmark and TOC menu links, they're just grayed out and inactive. There are no live text functions, nor active hyperlinks, on either device in any booktype, but font embedding is consistently present.
UPDATE 1/15/2013
The chart has been updated to incorporate the tests I ran on the Kindle eInk devices for ease of reference and comparison. This makes the text in the table somewhat smaller that I'd like, but this is a restriction of the blog format. You can easily use the zoom function on your monitor to increase the text size for better readability, or - since it's a live table and not an embedded image - copy and paste it into a word processor and increase the font size.
UPDATE 1/22/2013
Section 5/6 on Cover images has been updated with a note regarding the "start" attribute in the OPF Guide section. This is only tangentially related to cover images, but the discussion of the Guide functionality in that section made it seem the logical place to include this info.
January 21, 2013
Kindle Fixed Layout Template - Simple Version
When I started writing this new tutorial on formatting Kindle fixed layout ebooks I had every intention of just using the same KF8 template I had already posted back in March of last year. However, once I got down to the business end of detailing the many things that can be done with Kindle code, I quickly realized I needed to include a few more examples to illustrate what I was trying to describe.
Consequently, I began adding in new pages that would demonstrate such features as image switching, alternate text positioning, and page spread options. This, of course, required the creation of new content designed to demonstrate each point, and as usual I got carried away. The original template consisted of a mere five pages. The new one comes in at eighteen.
It also comes in two varieties. The first one, posted here today, is a somewhat truncated version of the full length one that will be completed in the next few days. This edition contains only images, with a single CSS file, and no table of contents (as seems to be the custom with most digital comics), making it very easy to use as the basis of your own project. There are no layers or separate text elements, but just a single image embedded in each page, albeit in a number of different ways. Specifically, there are three image referencing methods, plus three landscape layout styles (with two instances of each), these being single pages, two-page spreads with an inner margin, and two-page spreads combined into a single landscape image.
The tutorial posts discussing these elements will commence as soon as I polish off the advanced template, for which I still have one more page spread yet to finalize the art and layout. In the course of revising these new editions, I decided to create new art featuring the two characters who act as our hosts throughout the companion tutorial. Naturally, this became a much bigger task than I had planned.
Finally, rather than include the links here in this post, where they'll soon be lost to time, I have created a new "Templates" page that is linked to on the menu bar above. There you'll find links to all the templates I've created readily accessible and available for download. I will also be updating my iBooks template and tutorial as soon as this KF8 one is complete, as that is now well out of date, and missing several features added in the last major iBooks update. But that's a project for another day!
January 15, 2013
Kindle Fixed Layout Functionality [UPDATED 1-15-13]
Before we dive into the next portion of the tutorial, I thought it would be useful to post the following chart which comprises Appendix A of the ebook. This information will be discussed thoroughly and referred to throughout the tutorial, so having it beforehand might be helpful (especially since the ebook isn't out yet). And since much of it will make no sense without some explanation, I will provide a short introductory breakdown here as well. This will get a little technical, and may well make no sense at first for some of you (if so, just skip it for now and refer back when necessary), but it will all become clear in time. First, the chart...
Function
Booktype
Kindle
3
Paper
white
Fire
(Gen1)
HD7
HD9
PC
app
Android
app
1 - Page-Spread
Comic
Children
None
N/A
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
2 - Letterbox Color
Comic
Children
None
White
White
White
White
White
White
White
White
White
Black
White
White
Black
White
White
Choice
Choice
Choice
White
White
White
3 - Virtual Panels
Comic
Children
None
No
No
No
Yes
No
Yes
No
No
No
Yes
No
No
No
No
No
No
No
No
Yes
No
No
4 - HTML Image Zoom
Comic
Children
None
"Yes"
"Yes"
"Yes"
"Yes"
"Yes"
"Yes"
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
No
No
No
Yes
Yes
5 - Cover Image Access
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
6 - Cover Doubling
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
7 - TOC Menu Link
Comic
Children
None
No
No
No
No
No
No
Yes
Yes
Yes
No
NONE
No
No
NONE
No
Yes
Yes
Yes
Yes
Yes
Yes
8 - Bookmarks
Comic
Children
None
No
No
No
Yes
Yes
Yes
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
Yes
No
Yes
9 - Live Text Functions
Comic
Children
None
No
No
No
No
No
No
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
No
No
Yes
10 - Hyperlinks
Comic
Children
None
No
No
No
No
No
No
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
11 - Font Embedding
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Each of the 11 rows features one functionality element in KF8 that I have tested on the devices and apps listed in the five columns to the right. These are (in order): the Kindle for PC desktop application, a first generation Kindle Fire, the new Kindle HD 7" and HD 8.9" devices, and the Kindle for Android app. Unfortunately, I do not have a second generation Kindle Fire to test, nor a Mac on which to test the Kindle for Mac desktop application. And, of course, as mentioned in the Introduction, fixed layout files cannot be tested in the Kindle for iOS/iPad app, since transferring them in any way I have attempted (Dropbox / DiskAid / Send To Kindle) actually breaks the file. I didn't bother testing these on my Paperwhite or Kindle 3 keyboard model, since comics and graphic novels on these devices are pointless, even though technically they now support the format [see Update below].
As mentioned previously, there are two official book types for Kindle fixed layouts, defined by the appropriately titled "booktype" metadata value in the OPF file (to be discussed in an upcoming section), these being "children" and "comic." But, of course, you can also enter "none" (or simply leave it out), making essentially a third practical booktype. Unlike all the other Amazon-specific metadata values, which determine functionality for a specific listed attribute (such as fixed-layout or orientation, for example), the "booktype" attribute effects a broad range of overall ebook functionality - none of which is detailed by Amazon in their documentation. Hence, this chart. In it, each of the listed functions has been tested with each of the three booktype values set.
In addition, each of the three was tested with the RegionMagnification set both to "true" and to "false," since Amazon states in the Kindle Publishing Guidelines (Section 5.7) that the new Virtual Panels feature (row 3) is reliant upon this setting. This does not prove to be the case, as thorough testing resulted in no change whatsoever in the Virtual Panels functionality with either setting on any device or app. This, of course, may change in future updates, and I will update the chart accordingly at that time. But I have made no note of this distinction in the chart at present, since there is none.
Also, I should point out that in every case changing the booktype made no difference to the functionality of the Kindle for PC app, which appears to simply ignore the setting.
I have entered bold text for the results that stand out as the exception to the rule in order to make the disparity more readily apparent at a glance, and to point out issues with the functionality.
In addition, Appendix A provides no test results for region magnification features (aside from the new Virtual Panels function), as this is contained in Appendix B, and will be dealt with in the latter, more complex portions of the tutorial.
And now the breakdown...
1. Page Spread
A new function in KF8 is the "page-id" spine element which (purported) allows for the creation of two-page spreads in landscape mode (either with or without a margin in between). As you can see from the chart, this is only consistently true for the HD9 device, while the HD7 and Android app work correctly with the "comic" booktype value only. In all other cases only one page is shown at a time in landscape mode. Even the Kindle for PC app, which shows an activated two-page button icon, does not actually display two page spreads.
2. Letterbox Color
This refers to the color used to fill in any display space outside the page area, much like the "letterboxing" used in widescreen movies on a 4:3 format television (or iPad). I only tested this because I noticed it was sometimes black and sometimes white and wasn't really paying attention at first to when and where. As it turns out it's only black on the two new HD devices with the "comic" booktype chosen, and white at all other times, with the sole exception of Kindle for PC, where the three standard values of white, sepia, or black are all still available. Not critical, but sometimes one or the other blends better, so it interesting to know.
3. Virtual Panels
This new feature is apparently a fallback for fixed layout ebooks that have no custom region magnification elements included, and works by dividing the page into four equal quadrants (or "panels") that are zoomed by tapping and advanced in sequential order by swiping (the ordering being based on the "primary-writing-mode" value to allow for right-to-left and left-to-right reading order). Surprisingly, the zoomed page can also be scrolled around by dragging, making it actually a fairly nice feature for most fixed layout ebooks (in the absence of precisely placed mag zones, that is). As already mentioned, it is supposedly activated by default when the RegionMagnification value is "false," but this value actually has no effect at present: Virtual Panels either work on a particular Kindle reader or their don't, and in most cases they don't. In fact, in only two instances does this currently work: on the HD7 and Kindle for Android app, and only when the booktype is set to "comic." My guess is this feature will continue to roll out until all Kindle iterations have it - aside, perhaps, from the HD9, which somewhat surprisingly doesn't have it; but, then, it doesn't really need it due to its size. However, as you'll see in the next item, you can actually zoom images on the HD9 in certain instances.
4. HTML Image Zoom
This ties in somewhat with the last item, since only one or the other can work. This relates to the HTML <img src="http://feedproxy.google.com/~r/TheAdv... insertion method for adding background images in fixed layout, as opposed to the <div id="...> method of referencing a CSS background-image url. Amazon recommends the latter, but for reasons I will discuss later, I disagree (in fact, Section 4.2.3 of the Guidelines says it's a requirement, because "HTML images interfere with Region Magnification," which is demonstrably untrue). The important factor here, however, is that the <img src="http://feedproxy.google.com/~r/TheAdv... method allows the user to zoom a background image (including the cover) by double-tapping on it anywhere that it's not overlaid by text or Tap Targets, while the CSS method does not. This allows for zooming and scrolling entire background images (isolated from any text overlays), which until Virtual Panels was the only way this could be done. However, since the Virtual Panels function effectively creates a Tap Target covering the entire page, where that feature is active this one cannot be, since the background image cannot be tapped (the images still appear correctly, of course, so the insertion method still works for all intents and purposes). That said, assuming the RegionMag "true/false" value will eventually work as stated, you will then be able to chose one or the other, so this information will still theoretically be relevant. As seen in the chart, however, it's not just the Virtual Panels factor that determines whether Img Src Zoom works or not, since in no case does it work with the "comic" booktype value chosen. But since this is - at present - the only place where Virtual Panels works, in all other case (aside from Kindle for PC) this image zoom method works. An important distinction to make between Virtual Panels and the HTML "img src" method is that that latter only magnifies the actual background image (which is sometimes desirable and sometimes not), while Virtual Panels zooms the entire page, including text overlays, making it more like the iPad's pinch and zoom feature than Kindle's standard Panel View. (For an additional difficulty with Virtual Panels, see number 10. Hyperlinks below.)
5. Cover Image Access
6. HTML Cover Doubling
These two go hand-in-hand, and it all really comes down to one thing: Amazon flat out got it wrong on this one. In Sections 4.2.4 and 4.3.7 of the Kindle Publishing Guidelines Amazon either "requires" or "recommends" (depending on the section) than an HTML page containing the cover image be included in fixed layout files, even though in Section 3.2.3 they unequivocally state that you are not to do this because the cover image may appear twice - which is, in fact, exactly what happens in every instance. They then contradict themselves further by providing (in Section 3.2.3) one exception to this rule, in which case you must enter the linear="no" value to the spine entry for this element (the underlined element being "mandatory"); but then in the later two sections they state that the same value must be set to "yes." All this contradictory information can be cleared away easily by the facts: if an HTML cover is included it always appears twice. "Cover Image Access" simply refers to whether you can swipe back to the cover once you have moved forward into the book, and was tested in conjunction with the cover doubling issue to see how pervasive the latter was. In only one instance are you not able to return to the cover (even the HTML one) by swiping (or tapping), which is on the HD7. You can still access the cover via the menu link on this device, when again you will be presented with two consecutive covers, one JPEG, one HTML, but you cannot swipe back to it once into the book, whereas on every other device or app you can do so, and there will always be two consecutive cover images in a row, regardless. Moreover, and more importantly, including an HTML cover overrides the "start" Guide value for the "Go To Beginning" menu link, which will always go to the cover when an HTML cover is included, regardless of the "start" value given in the Guide, and even though there is already a cover link in the menu that renders this unnecessary and redundant. Without the HTML cover, you can use the "start" tag to point the "Beginning" menu link anywhere you like, and only one cover image will appear in your book. Therefore, there is simply no reason whatsoever to ever include an HTML cover, and several good reasons not to.
7. TOC Menu Link
Since we're on the subject of menu links, here's another issue. For some unfathomable reason, Amazon has decided to remove the "Table of Contents" link from the default "Go To" menu on the new HD devices. And not only that, but on ebooks with the "children" booktype value the entire "Go To" menu is inexplicably missing. Gone. Completely absent. No links to the cover, the beginning, or any other internal links. Apparently they think readers of children's ebooks don't use menus, nor that comics should ever have a Table of Contents - which they often don't, but lengthy graphic novels could certainly benefit from one. Perhaps they thought removing it was better than including a Go To menu where all the links are non-functional, but even so, removing the option is a bit reactionary, especially considering that the menu is still present and fully functional in all other Kindle readers.
8. Bookmarks
9. Live Text Functions (inc. Notes, Highlights, Search, & Definitions)
Of all the ebook functions that should never be disabled, these are them. If any feature promotes digital reading over print it's the ability to interact in highly useful and informative ways with the text. Being able to annotate, highlight (without ruining the book!), instantly search the entire text, and get the meaning of a word with just a tap of your finger - not to mention adding as many bookmarks as you like - are just some of the wonders that set ebooks apart. And yet Amazon has somehow decided (intentionally or inadvertently) that these features are not needed in children's books or comics. For with either of those booktypes entered they are all disabled, with the single exception of bookmarks in "comics" on the Android app. And mind you, this is not a fixed layout issue, not some odd quirk in the fixed layout Kindle code, since when you delete the booktype value altogether (or enter "none") all this functionality is back, with the fixed layout intact. It did not used to be this way for the "children" booktype, which originally retained live text functions, although "comic" did not have them from the very first. However, disabling them for children's ebooks only happened recently. I have ranted long and often on this here before, so I won't go on at length now. To me, there is simply no justification for this decision, since decision it must be, as there is no logical reason why a manufactured metadata value would have any effect it was not designed to have, unless Amazon is just not paying attention, which I find unlikely.
10. Hyperlinks
Somewhat similar to the live text problem is the issue of interactive links, both internal and external. Here there is fortunately only one disparity, which is on the HD7, where the "comic" booktype completely disables all text hyperlinks, none of which work at all. External hyperlinks are still blue, but non-active. This is clearly related to the Virtual Panels feature, rather than live text functions, since in all but this one instance hyperlinks work correctly even where live text is disabled. But as Virtual Panels currently only work on the HD7 and the Android app, it is possible that this feature is somehow interfering with the links, since Virtual Panels overlay the entire page with a tap target. However, given that the Android app is not effected, it's uncertain what is actually causing this. My concern is that as the Virtual Panels function is rolled out across devices the loss of hyperlinks might become a widespread problem. Hopefully the HD7 issue is an aberration, but it's 50/50 at the moment, so we'll just have to wait and see. Fortunately in most cases this is not an issue at present (which is little comfort to owners of a brand new HD7).
11. Font Embedding
This was just a standard test that I'm happy to report has essentially become unnecessary, as font embedding is now supported by all tested Kindle devices and apps. This was not the case just a few short years ago, when Kindle reflowable files did not allow custom fonts. Now they do, and KF8 has supported them from inception, and happily continues to do so. I include it because it's just good to know. And it's always nice to end on a positive note.
CONCLUSION
These are all considerations each ebook designer must weigh and make decisions on, based on their project and target audience. Bear in mind that digital publishing is still in its infancy, and in a state of great upheaval at the moment. All of this will settle out in time, but for now we have to be aware of what is possible and what is not, and try to stay abreast of any changes (which are numerous and often). Already this chart shows the great disparity between a single year's development of the Kindle Fire line: in at least half the features listed there is a difference in functionality between the 1st generation Fire and the latest models.
My biggest issue continues to be the lack of support for live text when either booktype value is entered, making my clear recommendation not to add one. The only functionality that will be lost by doing this are the two instances where Page Spread works with the comic value entered, but not when it is absent - these being the HD7 and Android app - as well as Virtual Panels on the same two readers. But since these features are hardly universal, being not yet present in any other case (aside from the HD9 where Page Spread is functional regardless of booktype), there is very little incentive to add a booktype value. The primary exception, unfortunately, is that only the "comic" booktype allows images of up to 800kb in size; otherwise, you're restricted to 256kb for fixed layouts, which can be a significant consideration with the advent of HD displays. Of course, this may all change (and probably will) over time as new updates are rolled out. But one cannot plan current work based on future possibilities. One must take what data is available today and use it to inform your present efforts.
As mentioned, I will update this chart regularly, and note the changes made at the bottom of the post. If a large number of changes are suddenly made - say, when a new line of devices arrives - I will do a new post and reevaluate the situation.
And by the way, if anyone has a 2nd generation Fire or a Mac with the Kindle desktop app and can test any of these features I would very much appreciate the information. I would love to add it to the chart for reference and will gladly give you ample credit and provide a link, both here and in the published ebook. For that matter, if any of your own testing contradicts what I have listed here, please let me know so I can look into it further. Comment below or send an email to scot(at)fantasycastlebooks.com.
UPDATE 1/6/2013
Just for the sake of being thorough, I went ahead and tested the eInk Kindle 3 and Paperwhite devices. And while I won't bother to include the data in the chart above due to space restrictions, I will point out the primary data points here.
First, and most surprising, is that the Paperwhite actually supports Page-Spread in all booktypes. This is accessed via the menu's "View in Landscape" option, since the Paperwhite has no internal orientation sensor. Just as interesting is the fact that, while the Kindle 3 does not support Page-Spread, it does default to landscape orientation for the booktype values "children" and "none" (though inexplicably showing only one page at a time), while for comics it reverts to portrait orientation. There is no way to change the orientation from the Kindle 3 menu. Letterbox color is white in each instance.
Equally surprising is support for Virtual Panels on the Paperwhite with "comic" or "none" booktypes (but not for children's books). This is, therefore, the only device that currently does so with the booktype absent, and only the second device that supports it at all. Why the eInk Paperwhite would support this function, but not the 1st gen Fire is beyond me (except that the Fire's OS has not been updated for some time).
Another curious fact is that pinch and zoom is available for all pages on the Paperwhite with any booktype setting, regardless of image insertion method. The Kindle 3 has some default zoom functions available via the menu, with incremental 5-way controller scrolling in all directions rather than the Virtual Panels' default quarter page progression. So that's a sort of "qualified" yes for that feature.
Cover issues remain consistent on both devices, and there are no Table of Contents menus in any instance. Bookmarks are functional in all three booktypes on the Paperwhite, but not at all on the Kindle 3, even though it retains the default Bookmark and TOC menu links, they're just grayed out and inactive. There are no live text functions, nor active hyperlinks, on either device in any booktype, but font embedding is consistently present.
UPDATE 1/15/2013
The chart has been updated to incorporate the tests I ran on the Kindle eInk devices for ease of reference and comparison. This makes the text in the table somewhat smaller that I'd like, but this is a restriction of the blog format. You can easily use the zoom function on your monitor to increase the text size for better readability, or - since it's a live table and not an embedded image - copy and paste it into a word processor and increase the font size.
Function
Booktype
Kindle
3
Paper
white
Fire
(Gen1)
HD7
HD9
PC
app
Android
app
1 - Page-Spread
Comic
Children
None
N/A
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
Yes
Yes
Yes
No
No
No
Yes
No
No
2 - Letterbox Color
Comic
Children
None
White
White
White
White
White
White
White
White
White
Black
White
White
Black
White
White
Choice
Choice
Choice
White
White
White
3 - Virtual Panels
Comic
Children
None
No
No
No
Yes
No
Yes
No
No
No
Yes
No
No
No
No
No
No
No
No
Yes
No
No
4 - HTML Image Zoom
Comic
Children
None
"Yes"
"Yes"
"Yes"
"Yes"
"Yes"
"Yes"
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
No
No
No
Yes
Yes
5 - Cover Image Access
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
6 - Cover Doubling
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
7 - TOC Menu Link
Comic
Children
None
No
No
No
No
No
No
Yes
Yes
Yes
No
NONE
No
No
NONE
No
Yes
Yes
Yes
Yes
Yes
Yes
8 - Bookmarks
Comic
Children
None
No
No
No
Yes
Yes
Yes
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
Yes
No
Yes
9 - Live Text Functions
Comic
Children
None
No
No
No
No
No
No
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
No
No
Yes
10 - Hyperlinks
Comic
Children
None
No
No
No
No
No
No
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
11 - Font Embedding
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Each of the 11 rows features one functionality element in KF8 that I have tested on the devices and apps listed in the five columns to the right. These are (in order): the Kindle for PC desktop application, a first generation Kindle Fire, the new Kindle HD 7" and HD 8.9" devices, and the Kindle for Android app. Unfortunately, I do not have a second generation Kindle Fire to test, nor a Mac on which to test the Kindle for Mac desktop application. And, of course, as mentioned in the Introduction, fixed layout files cannot be tested in the Kindle for iOS/iPad app, since transferring them in any way I have attempted (Dropbox / DiskAid / Send To Kindle) actually breaks the file. I didn't bother testing these on my Paperwhite or Kindle 3 keyboard model, since comics and graphic novels on these devices are pointless, even though technically they now support the format [see Update below].
As mentioned previously, there are two official book types for Kindle fixed layouts, defined by the appropriately titled "booktype" metadata value in the OPF file (to be discussed in an upcoming section), these being "children" and "comic." But, of course, you can also enter "none" (or simply leave it out), making essentially a third practical booktype. Unlike all the other Amazon-specific metadata values, which determine functionality for a specific listed attribute (such as fixed-layout or orientation, for example), the "booktype" attribute effects a broad range of overall ebook functionality - none of which is detailed by Amazon in their documentation. Hence, this chart. In it, each of the listed functions has been tested with each of the three booktype values set.
In addition, each of the three was tested with the RegionMagnification set both to "true" and to "false," since Amazon states in the Kindle Publishing Guidelines (Section 5.7) that the new Virtual Panels feature (row 3) is reliant upon this setting. This does not prove to be the case, as thorough testing resulted in no change whatsoever in the Virtual Panels functionality with either setting on any device or app. This, of course, may change in future updates, and I will update the chart accordingly at that time. But I have made no note of this distinction in the chart at present, since there is none.
Also, I should point out that in every case changing the booktype made no difference to the functionality of the Kindle for PC app, which appears to simply ignore the setting.
I have entered bold text for the results that stand out as the exception to the rule in order to make the disparity more readily apparent at a glance, and to point out issues with the functionality.
In addition, Appendix A provides no test results for region magnification features (aside from the new Virtual Panels function), as this is contained in Appendix B, and will be dealt with in the latter, more complex portions of the tutorial.
And now the breakdown...
1. Page Spread
A new function in KF8 is the "page-id" spine element which (purported) allows for the creation of two-page spreads in landscape mode (either with or without a margin in between). As you can see from the chart, this is only consistently true for the HD9 device, while the HD7 and Android app work correctly with the "comic" booktype value only. In all other cases only one page is shown at a time in landscape mode. Even the Kindle for PC app, which shows an activated two-page button icon, does not actually display two page spreads.
2. Letterbox Color
This refers to the color used to fill in any display space outside the page area, much like the "letterboxing" used in widescreen movies on a 4:3 format television (or iPad). I only tested this because I noticed it was sometimes black and sometimes white and wasn't really paying attention at first to when and where. As it turns out it's only black on the two new HD devices with the "comic" booktype chosen, and white at all other times, with the sole exception of Kindle for PC, where the three standard values of white, sepia, or black are all still available. Not critical, but sometimes one or the other blends better, so it interesting to know.
3. Virtual Panels
This new feature is apparently a fallback for fixed layout ebooks that have no custom region magnification elements included, and works by dividing the page into four equal quadrants (or "panels") that are zoomed by tapping and advanced in sequential order by swiping (the ordering being based on the "primary-writing-mode" value to allow for right-to-left and left-to-right reading order). Surprisingly, the zoomed page can also be scrolled around by dragging, making it actually a fairly nice feature for most fixed layout ebooks (in the absence of precisely placed mag zones, that is). As already mentioned, it is supposedly activated by default when the RegionMagnification value is "false," but this value actually has no effect at present: Virtual Panels either work on a particular Kindle reader or their don't, and in most cases they don't. In fact, in only two instances does this currently work: on the HD7 and Kindle for Android app, and only when the booktype is set to "comic." My guess is this feature will continue to roll out until all Kindle iterations have it - aside, perhaps, from the HD9, which somewhat surprisingly doesn't have it; but, then, it doesn't really need it due to its size. However, as you'll see in the next item, you can actually zoom images on the HD9 in certain instances.
4. HTML Image Zoom
This ties in somewhat with the last item, since only one or the other can work. This relates to the HTML <img src="http://feedproxy.google.com/~r/TheAdv... insertion method for adding background images in fixed layout, as opposed to the <div id="...> method of referencing a CSS background-image url. Amazon recommends the latter, but for reasons I will discuss later, I disagree (in fact, Section 4.2.3 of the Guidelines says it's a requirement, because "HTML images interfere with Region Magnification," which is demonstrably untrue). The important factor here, however, is that the <img src="http://feedproxy.google.com/~r/TheAdv... method allows the user to zoom a background image (including the cover) by double-tapping on it anywhere that it's not overlaid by text or Tap Targets, while the CSS method does not. This allows for zooming and scrolling entire background images (isolated from any text overlays), which until Virtual Panels was the only way this could be done. However, since the Virtual Panels function effectively creates a Tap Target covering the entire page, where that feature is active this one cannot be, since the background image cannot be tapped (the images still appear correctly, of course, so the insertion method still works for all intents and purposes). That said, assuming the RegionMag "true/false" value will eventually work as stated, you will then be able to chose one or the other, so this information will still theoretically be relevant. As seen in the chart, however, it's not just the Virtual Panels factor that determines whether Img Src Zoom works or not, since in no case does it work with the "comic" booktype value chosen. But since this is - at present - the only place where Virtual Panels works, in all other case (aside from Kindle for PC) this image zoom method works. An important distinction to make between Virtual Panels and the HTML "img src" method is that that latter only magnifies the actual background image (which is sometimes desirable and sometimes not), while Virtual Panels zooms the entire page, including text overlays, making it more like the iPad's pinch and zoom feature than Kindle's standard Panel View. (For an additional difficulty with Virtual Panels, see number 10. Hyperlinks below.)
5. Cover Image Access
6. HTML Cover Doubling
These two go hand-in-hand, and it all really comes down to one thing: Amazon flat out got it wrong on this one. In Sections 4.2.4 and 4.3.7 of the Kindle Publishing Guidelines Amazon either "requires" or "recommends" (depending on the section) than an HTML page containing the cover image be included in fixed layout files, even though in Section 3.2.3 they unequivocally state that you are not to do this because the cover image may appear twice - which is, in fact, exactly what happens in every instance. They then contradict themselves further by providing (in Section 3.2.3) one exception to this rule, in which case you must enter the linear="no" value to the spine entry for this element (the underlined element being "mandatory"); but then in the later two sections they state that the same value must be set to "yes." All this contradictory information can be cleared away easily by the facts: if an HTML cover is included it always appears twice. "Cover Image Access" simply refers to whether you can swipe back to the cover once you have moved forward into the book, and was tested in conjunction with the cover doubling issue to see how pervasive the latter was. In only one instance are you not able to return to the cover (even the HTML one) by swiping (or tapping), which is on the HD7. You can still access the cover via the menu link on this device, when again you will be presented with two consecutive covers, one JPEG, one HTML, but you cannot swipe back to it once into the book, whereas on every other device or app you can do so, and there will always be two consecutive cover images in a row, regardless. Moreover, and more importantly, including an HTML cover overrides the "start" Guide value for the "Go To Beginning" menu link, which will always go to the cover when an HTML cover is included, regardless of the "start" value given in the Guide, and even though there is already a cover link in the menu that renders this unnecessary and redundant. Without the HTML cover, you can use the "start" tag to point the "Beginning" menu link anywhere you like, and only one cover image will appear in your book. Therefore, there is simply no reason whatsoever to ever include an HTML cover, and several good reasons not to.
7. TOC Menu Link
Since we're on the subject of menu links, here's another issue. For some unfathomable reason, Amazon has decided to remove the "Table of Contents" link from the default "Go To" menu on the new HD devices. And not only that, but on ebooks with the "children" booktype value the entire "Go To" menu is inexplicably missing. Gone. Completely absent. No links to the cover, the beginning, or any other internal links. Apparently they think readers of children's ebooks don't use menus, nor that comics should ever have a Table of Contents - which they often don't, but lengthy graphic novels could certainly benefit from one. Perhaps they thought removing it was better than including a Go To menu where all the links are non-functional, but even so, removing the option is a bit reactionary, especially considering that the menu is still present and fully functional in all other Kindle readers.
8. Bookmarks
9. Live Text Functions (inc. Notes, Highlights, Search, & Definitions)
Of all the ebook functions that should never be disabled, these are them. If any feature promotes digital reading over print it's the ability to interact in highly useful and informative ways with the text. Being able to annotate, highlight (without ruining the book!), instantly search the entire text, and get the meaning of a word with just a tap of your finger - not to mention adding as many bookmarks as you like - are just some of the wonders that set ebooks apart. And yet Amazon has somehow decided (intentionally or inadvertently) that these features are not needed in children's books or comics. For with either of those booktypes entered they are all disabled, with the single exception of bookmarks in "comics" on the Android app. And mind you, this is not a fixed layout issue, not some odd quirk in the fixed layout Kindle code, since when you delete the booktype value altogether (or enter "none") all this functionality is back, with the fixed layout intact. It did not used to be this way for the "children" booktype, which originally retained live text functions, although "comic" did not have them from the very first. However, disabling them for children's ebooks only happened recently. I have ranted long and often on this here before, so I won't go on at length now. To me, there is simply no justification for this decision, since decision it must be, as there is no logical reason why a manufactured metadata value would have any effect it was not designed to have, unless Amazon is just not paying attention, which I find unlikely.
10. Hyperlinks
Somewhat similar to the live text problem is the issue of interactive links, both internal and external. Here there is fortunately only one disparity, which is on the HD7, where the "comic" booktype completely disables all text hyperlinks, none of which work at all. External hyperlinks are still blue, but non-active. This is clearly related to the Virtual Panels feature, rather than live text functions, since in all but this one instance hyperlinks work correctly even where live text is disabled. But as Virtual Panels currently only work on the HD7 and the Android app, it is possible that this feature is somehow interfering with the links, since Virtual Panels overlay the entire page with a tap target. However, given that the Android app is not effected, it's uncertain what is actually causing this. My concern is that as the Virtual Panels function is rolled out across devices the loss of hyperlinks might become a widespread problem. Hopefully the HD7 issue is an aberration, but it's 50/50 at the moment, so we'll just have to wait and see. Fortunately in most cases this is not an issue at present (which is little comfort to owners of a brand new HD7).
11. Font Embedding
This was just a standard test that I'm happy to report has essentially become unnecessary, as font embedding is now supported by all tested Kindle devices and apps. This was not the case just a few short years ago, when Kindle reflowable files did not allow custom fonts. Now they do, and KF8 has supported them from inception, and happily continues to do so. I include it because it's just good to know. And it's always nice to end on a positive note.
CONCLUSION
These are all considerations each ebook designer must weigh and make decisions on, based on their project and target audience. Bear in mind that digital publishing is still in its infancy, and in a state of great upheaval at the moment. All of this will settle out in time, but for now we have to be aware of what is possible and what is not, and try to stay abreast of any changes (which are numerous and often). Already this chart shows the great disparity between a single year's development of the Kindle Fire line: in at least half the features listed there is a difference in functionality between the 1st generation Fire and the latest models.
My biggest issue continues to be the lack of support for live text when either booktype value is entered, making my clear recommendation not to add one. The only functionality that will be lost by doing this are the two instances where Page Spread works with the comic value entered, but not when it is absent - these being the HD7 and Android app - as well as Virtual Panels on the same two readers. But since these features are hardly universal, being not yet present in any other case (aside from the HD9 where Page Spread is functional regardless of booktype), there is very little incentive to add a booktype value. The primary exception, unfortunately, is that only the "comic" booktype allows images of up to 800kb in size; otherwise, you're restricted to 256kb for fixed layouts, which can be a significant consideration with the advent of HD displays. Of course, this may all change (and probably will) over time as new updates are rolled out. But one cannot plan current work based on future possibilities. One must take what data is available today and use it to inform your present efforts.
As mentioned, I will update this chart regularly, and note the changes made at the bottom of the post. If a large number of changes are suddenly made - say, when a new line of devices arrives - I will do a new post and reevaluate the situation.
And by the way, if anyone has a 2nd generation Fire or a Mac with the Kindle desktop app and can test any of these features I would very much appreciate the information. I would love to add it to the chart for reference and will gladly give you ample credit and provide a link, both here and in the published ebook. For that matter, if any of your own testing contradicts what I have listed here, please let me know so I can look into it further. Comment below or send an email to scot(at)fantasycastlebooks.com.
UPDATE 1/6/2013
Just for the sake of being thorough, I went ahead and tested the eInk Kindle 3 and Paperwhite devices. And while I won't bother to include the data in the chart above due to space restrictions, I will point out the primary data points here.
First, and most surprising, is that the Paperwhite actually supports Page-Spread in all booktypes. This is accessed via the menu's "View in Landscape" option, since the Paperwhite has no internal orientation sensor. Just as interesting is the fact that, while the Kindle 3 does not support Page-Spread, it does default to landscape orientation for the booktype values "children" and "none" (though inexplicably showing only one page at a time), while for comics it reverts to portrait orientation. There is no way to change the orientation from the Kindle 3 menu. Letterbox color is white in each instance.
Equally surprising is support for Virtual Panels on the Paperwhite with "comic" or "none" booktypes (but not for children's books). This is, therefore, the only device that currently does so with the booktype absent, and only the second device that supports it at all. Why the eInk Paperwhite would support this function, but not the 1st gen Fire is beyond me (except that the Fire's OS has not been updated for some time).
Another curious fact is that pinch and zoom is available for all pages on the Paperwhite with any booktype setting, regardless of image insertion method. The Kindle 3 has some default zoom functions available via the menu, with incremental 5-way controller scrolling in all directions rather than the Virtual Panels' default quarter page progression. So that's a sort of "qualified" yes for that feature.
Cover issues remain consistent on both devices, and there are no Table of Contents menus in any instance. Bookmarks are functional in all three booktypes on the Paperwhite, but not at all on the Kindle 3, even though it retains the default Bookmark and TOC menu links, they're just grayed out and inactive. There are no live text functions, nor active hyperlinks, on either device in any booktype, but font embedding is consistently present.
UPDATE 1/15/2013
The chart has been updated to incorporate the tests I ran on the Kindle eInk devices for ease of reference and comparison. This makes the text in the table somewhat smaller that I'd like, but this is a restriction of the blog format. You can easily use the zoom function on your monitor to increase the text size for better readability, or - since it's a live table and not an embedded image - copy and paste it into a word processor and increase the font size.
January 6, 2013
Kindle Fixed Layout Functionality
Before we dive into the next portion of the tutorial, I thought it would be useful to post the following chart which comprises Appendix A of the ebook. This information will be discussed thoroughly and referred to throughout the tutorial, so having it beforehand might be helpful (especially since the ebook isn't out yet). And since much of it will make no sense without some explanation, I will provide a short introductory breakdown here as well. This will get a little technical, and may well make no sense at first for some of you (if so, just skip it for now and refer back when necessary), but it will all become clear in time. First, the chart...
Function
Booktype
PC
Fire
(Gen1)
HD7
HD9
Android
1 - Page-Spread
Comic
Children
None
No
No
No
No
No
No
Yes
No
No
Yes
Yes
Yes
Yes
No
No
2 - Letterbox Color
Comic
Children
None
Choice
Choice
Choice
White
White
White
Black
White
White
Black
White
White
White
White
White
3 - Virtual Panels
Comic
Children
None
No
No
No
No
No
No
Yes
No
No
No
No
No
Yes
No
No
4 - HTML Image Zoom
Comic
Children
None
No
No
No
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
5 - Cover Image Access
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
6 - HTML Cover Doubling
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
7 - TOC Menu Link
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
No
NONE
No
No
NONE
No
Yes
Yes
Yes
8 - Bookmarks
Comic
Children
None
Yes
Yes
Yes
No
No
Yes
No
No
Yes
No
No
Yes
Yes
No
Yes
9 - Live Text Functions
Comic
Children
None
Yes
Yes
Yes
No
No
Yes
No
No
Yes
No
No
Yes
No
No
Yes
10 - Hyperlinks
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
11 - Font Embedding
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Each of the 11 rows features one functionality element in KF8 that I have tested on the devices and apps listed in the five columns to the right. These are (in order): the Kindle for PC desktop application, a first generation Kindle Fire, the new Kindle HD 7" and HD 8.9" devices, and the Kindle for Android app. Unfortunately, I do not have a second generation Kindle Fire to test, nor a Mac on which to test the Kindle for Mac desktop application. And, of course, as mentioned in the Introduction, fixed layout files cannot be tested in the Kindle for iOS/iPad app, since transferring them in any way I have attempted (Dropbox / DiskAid / Send To Kindle) actually breaks the file. I didn't bother testing these on my Paperwhite or Kindle 3 keyboard model, since comics and graphic novels on these devices are pointless, even though technically they now support the format [see Update below].
As mentioned previously, there are two official book types for Kindle fixed layouts, defined by the appropriately titled "booktype" metadata value in the OPF file (to be discussed in an upcoming section), these being "children" and "comic." But, of course, you can also enter "none" (or simply leave it out), making essentially a third practical booktype. Thus, each functionality element has been tested with each of these three options set.
In addition, each of the three was tested with the RegionMagnification set both to "true" and to "false," since Amazon states in the Kindle Publishing Guidelines (Section 5.7) that the new Virtual Panels feature (row 3) is reliant upon this setting. This does not prove to be the case, as thorough testing resulted in no change whatsoever in the Virtual Panels functionality with either setting on any device or app. This, of course, may change in future updates, and I will update the chart accordingly at that time. But I have made no note of this distinction in the chart at present, since there is none.
Also, I should point out that in every case changing the booktype made no difference to the functionality of the Kindle for PC app, which appears to simply ignore the setting.
I have entered bold text for the results that stand out as the exception to the rule in order to make the disparity more readily apparent at a glance, and to point out issues with the functionality.
In addition, Appendix A provides no test results for region magnification features (aside from the new Virtual Panels function), as this is contained in Appendix B, and will be dealt with in the latter, more complex portions of the tutorial.
And now the breakdown...
1. Page Spread
A new function in KF8 is the "page-id" spine element which (purported) allows for the creation of two-page spreads in landscape mode (either with or without a margin in between). As you can see from the chart, this is only consistently true for the HD9 device, while the HD7 and Android app work correctly with the "comic" booktype value only. In all other cases only one page is shown at a time in landscape mode. Even the Kindle for PC app, which shows an activated two-page button icon, does not actually display two page spreads.
2. Letterbox Color
This refers to the color used to fill in any display space outside the page area, much like the "letterboxing" used in widescreen movies on a 4:3 format television (or iPad). I only tested this because I noticed it was sometimes black and sometimes white and wasn't really paying attention at first to when and where. As it turns out it's only black on the two new HD devices with the "comic" booktype chosen, and white at all other times, with the sole exception of Kindle for PC, where the three standard values of white, sepia, or black are all still available. Not critical, but sometimes one or the other blends better, so it interesting to know.
3. Virtual Panels
This new feature is apparently a fallback for fixed layout ebooks that have no custom region magnification elements included, and works by dividing the page into four equal quadrants (or "panels") that are zoomed by tapping and advanced in sequential order by swiping (the ordering being based on the "primary-writing-mode" value to allow for right-to-left and left-to-right reading order). Surprisingly, the zoomed page can also be scrolled around by dragging, making it actually a fairly nice feature for most fixed layout ebooks (in the absence of precisely placed mag zones, that is). As already mentioned, it is supposedly activated by default when the RegionMagnification value is "false," but this value actually has no effect at present: Virtual Panels either work on a particular Kindle reader or their don't, and in most cases they don't. In fact, in only two instances does this currently work: on the HD7 and Kindle for Android app, and only when the booktype is set to "comic." My guess is this feature will continue to roll out until all Kindle iterations have it - aside, perhaps, from the HD9, which somewhat surprisingly doesn't have it; but, then, it doesn't really need it due to its size. However, as you'll see in the next item, you can actually zoom images on the HD9 in certain instances.
4. HTML Image Zoom
This ties in somewhat with the last item, since only one or the other can work. This relates to the HTML <img src="http://feedproxy.google.com/~r/TheAdv... insertion method for adding background images in fixed layout, as opposed to the <div id="...> method of referencing a CSS background-image url. Amazon recommends the latter, but for reasons I will discuss later, I disagree (in fact, Section 4.2.3 of the Guidelines says it's a requirement, because "HTML images interfere with Region Magnification," which is demonstrably untrue). The important factor here, however, is that the <img src="http://feedproxy.google.com/~r/TheAdv... method allows the user to zoom a background image (including the cover) by double-tapping on it anywhere that it's not overlaid by text or Tap Targets, while the CSS method does not. This allows for zooming and scrolling entire background images (isolated from any text overlays), which until Virtual Panels was the only way this could be done. However, since the Virtual Panels function effectively creates a Tap Target covering the entire page, where that feature is active this one cannot be, since the background image cannot be tapped (the images still appear correctly, of course, so the insertion method still works for all intents and purposes). That said, assuming the RegionMag "true/false" value will eventually work as stated, you will then be able to chose one or the other, so this information will still theoretically be relevant. As seen in the chart, however, it's not just the Virtual Panels factor that determines whether Img Src Zoom works or not, since in no case does it work with the "comic" booktype value chosen. But since this is - at present - the only place where Virtual Panels works, in all other case (aside from Kindle for PC) this image zoom method works. An important distinction to make between Virtual Panels and the HTML "img src" method is that that latter only magnifies the actual background image (which is sometimes desirable and sometimes not), while Virtual Panels zooms the entire page, including text overlays, making it more like the iPad's pinch and zoom feature than Kindle's standard Panel View. (For an additional difficulty with Virtual Panels, see number 10. Hyperlinks below.)
5. Cover Image Access
6. HTML Cover Doubling
These two go hand-in-hand, and it all really comes down to one thing: Amazon flat out got it wrong on this one. In Sections 4.2.4 and 4.3.7 of the Kindle Publishing Guidelines Amazon either "requires" or "recommends" (depending on the section) than an HTML page containing the cover image be included in fixed layout files, even though in Section 3.2.3 they unequivocally state that you are not to do this because the cover image may appear twice - which is, in fact, exactly what happens in every instance. They then contradict themselves further by providing (in Section 3.2.3) one exception to this rule, in which case you must enter the linear="no" value to the spine entry for this element (the underlined element being "mandatory"); but then in the later two sections they state that the same value must be set to "yes." All this contradictory information can be cleared away easily by the facts: if an HTML cover is included it always appears twice. "Cover Image Access" simply refers to whether you can swipe back to the cover once you have moved forward into the book, and was tested in conjunction with the cover doubling issue to see how pervasive the latter was. In only one instance are you not able to return to the cover (even the HTML one) by swiping (or tapping), which is on the HD7. You can still access the cover via the menu link on this device, when again you will be presented with two consecutive covers, one JPEG, one HTML, but you cannot swipe back to it once into the book, whereas on every other device or app you can do so, and there will always be two consecutive cover images in a row, regardless. Moreover, and more importantly, including an HTML cover overrides the "start" Guide value for the "Go To Beginning" menu link, which will always go to the cover when an HTML cover is included, regardless of the "start" value given in the Guide, and even though there is already a cover link in the menu that renders this unnecessary and redundant. Without the HTML cover, you can use the "start" tag to point the "Beginning" menu link anywhere you like, and only one cover image will appear in your book. Therefore, there is simply no reason whatsoever to ever include an HTML cover, and several good reasons not to.
7. TOC Menu Link
Since we're on the subject of menu links, here's another issue. For some unfathomable reason, Amazon has decided to remove the "Table of Contents" link from the default "Go To" menu on the new HD devices. And not only that, but on ebooks with the "children" booktype value the entire "Go To" menu is inexplicably missing. Gone. Completely absent. No links to the cover, the beginning, or any other internal links. Apparently they think readers of children's ebooks don't use menus, nor that comics should ever have a Table of Contents - which they often don't, but lengthy graphic novels could certainly benefit from one. Perhaps they thought removing it was better than including a Go To menu where all the links are non-functional, but even so, removing the option is a bit reactionary, especially considering that the menu is still present and fully functional in all other Kindle readers.
8. Bookmarks
9. Live Text Functions (inc. Notes, Highlights, Search, & Definitions)
Of all the ebook functions that should never be disabled, these are them. If any feature promotes digital reading over print it's the ability to interact in highly useful and informative ways with the text. Being able to annotate, highlight (without ruining the book!), instantly search the entire text, and get the meaning of a word with just a tap of your finger - not to mention adding as many bookmarks as you like - are just some of the wonders that set ebooks apart. And yet Amazon has somehow decided (intentionally or inadvertently) that these features are not needed in children's books or comics. For with either of those booktypes entered they are all disabled, with the single exception of bookmarks in "comics" on the Android app. And mind you, this is not a fixed layout issue, not some odd quirk in the fixed layout Kindle code, since when you delete the booktype value altogether (or enter "none") all this functionality is back, with the fixed layout intact. It did not used to be this way for the "children" booktype, which originally retained live text functions, although "comic" did not have them from the very first. However, disabling them for children's ebooks only happened recently. I have ranted long and often on this here before, so I won't go on at length now. To me, there is simply no justification for this decision, since decision it must be, as there is no logical reason why a manufactured metadata value would have any effect it was not designed to have, unless Amazon is just not paying attention, which I find unlikely.
10. Hyperlinks
Somewhat similar to the live text problem is the issue of interactive links, both internal and external. Here there is fortunately only one disparity, which is on the HD7, where the "comic" booktype completely disables all text hyperlinks, none of which work at all. External hyperlinks are still blue, but non-active. This is clearly related to the Virtual Panels feature, rather than live text functions, since in all but this one instance hyperlinks work correctly even where live text is disabled. But as Virtual Panels currently only work on the HD7 and the Android app, it is possible that this feature is somehow interfering with the links, since Virtual Panels overlay the entire page with a tap target. However, given that the Android app is not effected, it's uncertain what is actually causing this. My concern is that as the Virtual Panels function is rolled out across devices the loss of hyperlinks might become a widespread problem. Hopefully the HD7 issue is an aberration, but it's 50/50 at the moment, so we'll just have to wait and see. Fortunately in most cases this is not an issue at present (which is little comfort to owners of a brand new HD7).
11. Font Embedding
This was just a standard test that I'm happy to report has essentially become unnecessary, as font embedding is now supported by all tested Kindle devices and apps. This was not the case just a few short years ago, when Kindle reflowable files did not allow custom fonts. Now they do, and KF8 has supported them from inception, and happily continues to do so. I include it because it's just good to know. And it's always nice to end on a positive note.
CONCLUSION
These are all considerations each ebook designer must weigh and make decisions on, based on their project and target audience. Bear in mind that digital publishing is still in its infancy, and in a state of great upheaval at the moment. All of this will settle out in time, but for now we have to be aware of what is possible and what is not, and try to stay abreast of any changes (which are numerous and often). Already this chart shows the great disparity between a single year's development of the Kindle Fire line: in at least half the features listed there is a difference in functionality between the 1st generation Fire and the latest models.
My biggest issue continues to be the lack of support for live text when either booktype value is entered, making my clear recommendation not to add one. The only functionality that will be lost by doing this are the two instances where Page Spread works with the comic value entered, but not when it is absent - these being the HD7 and Android app - as well as Virtual Panels on the same two readers. But since these features are hardly universal, being not yet present in any other case (aside from the HD9 where Page Spread is functional regardless of booktype), there is very little incentive to add a booktype value. The primary exception, unfortunately, is that only the "comic" booktype allows images of up to 800kb in size; otherwise, you're restricted to 256kb for fixed layouts, which can be a significant consideration with the advent of HD displays. Of course, this may all change (and probably will) over time as new updates are rolled out. But one cannot plan current work based on future possibilities. One must take what data is available today and use it to inform your present efforts.
As mentioned, I will update this chart regularly, and note the changes made at the bottom of the post. If a large number of changes are suddenly made - say, when a new line of devices arrives - I will do a new post and reevaluate the situation.
And by the way, if anyone has a 2nd generation Fire or a Mac with the Kindle desktop app and can test any of these features I would very much appreciate the information. I would love to add it to the chart for reference and will gladly give you ample credit and provide a link, both here and in the published ebook. For that matter, if any of your own testing contradicts what I have listed here, please let me know so I can look into it further. Comment below or send an email to scot(at)fantasycastlebooks.com.
UPDATE 1/6/2013 4:00 P.M.
Just for the sake of being thorough, I went ahead and tested the eInk Kindle 3 and Paperwhite devices. And while I won't bother to include the data in the chart above due to space restrictions, I will point out the primary data points here.
First, and most surprising, is that the Paperwhite actually supports Page-Spread in all booktypes. This is accessed via the menu's "View in Landscape" option, since the Paperwhite has no internal orientation sensor. Just as interesting is the fact that, while the Kindle 3 does not support Page-Spread, it does default to landscape orientation for the booktype values "children" and "none" (though inexplicably showing only one page at a time), while for comics it reverts to portrait orientation. There is no way to change the orientation from the Kindle 3 menu. Letterbox color is white in each instance.
Equally surprising is support for Virtual Panels on the Paperwhite with "comic" or "none" booktypes (but not for children's books). This is, therefore, the only device that currently does so with the booktype absent, and only the second device that supports it at all. Why the eInk Paperwhite would support this function, but not the 1st gen Fire is beyond me (except that the Fire's OS has not been updated for some time).
Another curious fact is that pinch and zoom is available for all pages on the Paperwhite with any booktype setting, regardless of image insertion method. The Kindle 3 has some default zoom functions available via the menu, with incremental 5-way controller scrolling in all directions rather than the Virtual Panels' default quarter page progression. So that's a sort of "qualified" yes for that feature.
Cover issues remain consistent on both devices, and there are no Table of Contents menus in any instance. Bookmarks are functional in all three booktypes on the Paperwhite, but not at all on the Kindle 3, even though it retains the default Bookmark and TOC menu links, they're just grayed out and inactive. There are no live text functions, nor active hyperlinks, on either device in any booktype, but font embedding is consistently present.
Function
Booktype
PC
Fire
(Gen1)
HD7
HD9
Android
1 - Page-Spread
Comic
Children
None
No
No
No
No
No
No
Yes
No
No
Yes
Yes
Yes
Yes
No
No
2 - Letterbox Color
Comic
Children
None
Choice
Choice
Choice
White
White
White
Black
White
White
Black
White
White
White
White
White
3 - Virtual Panels
Comic
Children
None
No
No
No
No
No
No
Yes
No
No
No
No
No
Yes
No
No
4 - HTML Image Zoom
Comic
Children
None
No
No
No
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
No
Yes
Yes
5 - Cover Image Access
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
6 - HTML Cover Doubling
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
7 - TOC Menu Link
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
No
NONE
No
No
NONE
No
Yes
Yes
Yes
8 - Bookmarks
Comic
Children
None
Yes
Yes
Yes
No
No
Yes
No
No
Yes
No
No
Yes
Yes
No
Yes
9 - Live Text Functions
Comic
Children
None
Yes
Yes
Yes
No
No
Yes
No
No
Yes
No
No
Yes
No
No
Yes
10 - Hyperlinks
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
11 - Font Embedding
Comic
Children
None
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Each of the 11 rows features one functionality element in KF8 that I have tested on the devices and apps listed in the five columns to the right. These are (in order): the Kindle for PC desktop application, a first generation Kindle Fire, the new Kindle HD 7" and HD 8.9" devices, and the Kindle for Android app. Unfortunately, I do not have a second generation Kindle Fire to test, nor a Mac on which to test the Kindle for Mac desktop application. And, of course, as mentioned in the Introduction, fixed layout files cannot be tested in the Kindle for iOS/iPad app, since transferring them in any way I have attempted (Dropbox / DiskAid / Send To Kindle) actually breaks the file. I didn't bother testing these on my Paperwhite or Kindle 3 keyboard model, since comics and graphic novels on these devices are pointless, even though technically they now support the format [see Update below].
As mentioned previously, there are two official book types for Kindle fixed layouts, defined by the appropriately titled "booktype" metadata value in the OPF file (to be discussed in an upcoming section), these being "children" and "comic." But, of course, you can also enter "none" (or simply leave it out), making essentially a third practical booktype. Thus, each functionality element has been tested with each of these three options set.
In addition, each of the three was tested with the RegionMagnification set both to "true" and to "false," since Amazon states in the Kindle Publishing Guidelines (Section 5.7) that the new Virtual Panels feature (row 3) is reliant upon this setting. This does not prove to be the case, as thorough testing resulted in no change whatsoever in the Virtual Panels functionality with either setting on any device or app. This, of course, may change in future updates, and I will update the chart accordingly at that time. But I have made no note of this distinction in the chart at present, since there is none.
Also, I should point out that in every case changing the booktype made no difference to the functionality of the Kindle for PC app, which appears to simply ignore the setting.
I have entered bold text for the results that stand out as the exception to the rule in order to make the disparity more readily apparent at a glance, and to point out issues with the functionality.
In addition, Appendix A provides no test results for region magnification features (aside from the new Virtual Panels function), as this is contained in Appendix B, and will be dealt with in the latter, more complex portions of the tutorial.
And now the breakdown...
1. Page Spread
A new function in KF8 is the "page-id" spine element which (purported) allows for the creation of two-page spreads in landscape mode (either with or without a margin in between). As you can see from the chart, this is only consistently true for the HD9 device, while the HD7 and Android app work correctly with the "comic" booktype value only. In all other cases only one page is shown at a time in landscape mode. Even the Kindle for PC app, which shows an activated two-page button icon, does not actually display two page spreads.
2. Letterbox Color
This refers to the color used to fill in any display space outside the page area, much like the "letterboxing" used in widescreen movies on a 4:3 format television (or iPad). I only tested this because I noticed it was sometimes black and sometimes white and wasn't really paying attention at first to when and where. As it turns out it's only black on the two new HD devices with the "comic" booktype chosen, and white at all other times, with the sole exception of Kindle for PC, where the three standard values of white, sepia, or black are all still available. Not critical, but sometimes one or the other blends better, so it interesting to know.
3. Virtual Panels
This new feature is apparently a fallback for fixed layout ebooks that have no custom region magnification elements included, and works by dividing the page into four equal quadrants (or "panels") that are zoomed by tapping and advanced in sequential order by swiping (the ordering being based on the "primary-writing-mode" value to allow for right-to-left and left-to-right reading order). Surprisingly, the zoomed page can also be scrolled around by dragging, making it actually a fairly nice feature for most fixed layout ebooks (in the absence of precisely placed mag zones, that is). As already mentioned, it is supposedly activated by default when the RegionMagnification value is "false," but this value actually has no effect at present: Virtual Panels either work on a particular Kindle reader or their don't, and in most cases they don't. In fact, in only two instances does this currently work: on the HD7 and Kindle for Android app, and only when the booktype is set to "comic." My guess is this feature will continue to roll out until all Kindle iterations have it - aside, perhaps, from the HD9, which somewhat surprisingly doesn't have it; but, then, it doesn't really need it due to its size. However, as you'll see in the next item, you can actually zoom images on the HD9 in certain instances.
4. HTML Image Zoom
This ties in somewhat with the last item, since only one or the other can work. This relates to the HTML <img src="http://feedproxy.google.com/~r/TheAdv... insertion method for adding background images in fixed layout, as opposed to the <div id="...> method of referencing a CSS background-image url. Amazon recommends the latter, but for reasons I will discuss later, I disagree (in fact, Section 4.2.3 of the Guidelines says it's a requirement, because "HTML images interfere with Region Magnification," which is demonstrably untrue). The important factor here, however, is that the <img src="http://feedproxy.google.com/~r/TheAdv... method allows the user to zoom a background image (including the cover) by double-tapping on it anywhere that it's not overlaid by text or Tap Targets, while the CSS method does not. This allows for zooming and scrolling entire background images (isolated from any text overlays), which until Virtual Panels was the only way this could be done. However, since the Virtual Panels function effectively creates a Tap Target covering the entire page, where that feature is active this one cannot be, since the background image cannot be tapped (the images still appear correctly, of course, so the insertion method still works for all intents and purposes). That said, assuming the RegionMag "true/false" value will eventually work as stated, you will then be able to chose one or the other, so this information will still theoretically be relevant. As seen in the chart, however, it's not just the Virtual Panels factor that determines whether Img Src Zoom works or not, since in no case does it work with the "comic" booktype value chosen. But since this is - at present - the only place where Virtual Panels works, in all other case (aside from Kindle for PC) this image zoom method works. An important distinction to make between Virtual Panels and the HTML "img src" method is that that latter only magnifies the actual background image (which is sometimes desirable and sometimes not), while Virtual Panels zooms the entire page, including text overlays, making it more like the iPad's pinch and zoom feature than Kindle's standard Panel View. (For an additional difficulty with Virtual Panels, see number 10. Hyperlinks below.)
5. Cover Image Access
6. HTML Cover Doubling
These two go hand-in-hand, and it all really comes down to one thing: Amazon flat out got it wrong on this one. In Sections 4.2.4 and 4.3.7 of the Kindle Publishing Guidelines Amazon either "requires" or "recommends" (depending on the section) than an HTML page containing the cover image be included in fixed layout files, even though in Section 3.2.3 they unequivocally state that you are not to do this because the cover image may appear twice - which is, in fact, exactly what happens in every instance. They then contradict themselves further by providing (in Section 3.2.3) one exception to this rule, in which case you must enter the linear="no" value to the spine entry for this element (the underlined element being "mandatory"); but then in the later two sections they state that the same value must be set to "yes." All this contradictory information can be cleared away easily by the facts: if an HTML cover is included it always appears twice. "Cover Image Access" simply refers to whether you can swipe back to the cover once you have moved forward into the book, and was tested in conjunction with the cover doubling issue to see how pervasive the latter was. In only one instance are you not able to return to the cover (even the HTML one) by swiping (or tapping), which is on the HD7. You can still access the cover via the menu link on this device, when again you will be presented with two consecutive covers, one JPEG, one HTML, but you cannot swipe back to it once into the book, whereas on every other device or app you can do so, and there will always be two consecutive cover images in a row, regardless. Moreover, and more importantly, including an HTML cover overrides the "start" Guide value for the "Go To Beginning" menu link, which will always go to the cover when an HTML cover is included, regardless of the "start" value given in the Guide, and even though there is already a cover link in the menu that renders this unnecessary and redundant. Without the HTML cover, you can use the "start" tag to point the "Beginning" menu link anywhere you like, and only one cover image will appear in your book. Therefore, there is simply no reason whatsoever to ever include an HTML cover, and several good reasons not to.
7. TOC Menu Link
Since we're on the subject of menu links, here's another issue. For some unfathomable reason, Amazon has decided to remove the "Table of Contents" link from the default "Go To" menu on the new HD devices. And not only that, but on ebooks with the "children" booktype value the entire "Go To" menu is inexplicably missing. Gone. Completely absent. No links to the cover, the beginning, or any other internal links. Apparently they think readers of children's ebooks don't use menus, nor that comics should ever have a Table of Contents - which they often don't, but lengthy graphic novels could certainly benefit from one. Perhaps they thought removing it was better than including a Go To menu where all the links are non-functional, but even so, removing the option is a bit reactionary, especially considering that the menu is still present and fully functional in all other Kindle readers.
8. Bookmarks
9. Live Text Functions (inc. Notes, Highlights, Search, & Definitions)
Of all the ebook functions that should never be disabled, these are them. If any feature promotes digital reading over print it's the ability to interact in highly useful and informative ways with the text. Being able to annotate, highlight (without ruining the book!), instantly search the entire text, and get the meaning of a word with just a tap of your finger - not to mention adding as many bookmarks as you like - are just some of the wonders that set ebooks apart. And yet Amazon has somehow decided (intentionally or inadvertently) that these features are not needed in children's books or comics. For with either of those booktypes entered they are all disabled, with the single exception of bookmarks in "comics" on the Android app. And mind you, this is not a fixed layout issue, not some odd quirk in the fixed layout Kindle code, since when you delete the booktype value altogether (or enter "none") all this functionality is back, with the fixed layout intact. It did not used to be this way for the "children" booktype, which originally retained live text functions, although "comic" did not have them from the very first. However, disabling them for children's ebooks only happened recently. I have ranted long and often on this here before, so I won't go on at length now. To me, there is simply no justification for this decision, since decision it must be, as there is no logical reason why a manufactured metadata value would have any effect it was not designed to have, unless Amazon is just not paying attention, which I find unlikely.
10. Hyperlinks
Somewhat similar to the live text problem is the issue of interactive links, both internal and external. Here there is fortunately only one disparity, which is on the HD7, where the "comic" booktype completely disables all text hyperlinks, none of which work at all. External hyperlinks are still blue, but non-active. This is clearly related to the Virtual Panels feature, rather than live text functions, since in all but this one instance hyperlinks work correctly even where live text is disabled. But as Virtual Panels currently only work on the HD7 and the Android app, it is possible that this feature is somehow interfering with the links, since Virtual Panels overlay the entire page with a tap target. However, given that the Android app is not effected, it's uncertain what is actually causing this. My concern is that as the Virtual Panels function is rolled out across devices the loss of hyperlinks might become a widespread problem. Hopefully the HD7 issue is an aberration, but it's 50/50 at the moment, so we'll just have to wait and see. Fortunately in most cases this is not an issue at present (which is little comfort to owners of a brand new HD7).
11. Font Embedding
This was just a standard test that I'm happy to report has essentially become unnecessary, as font embedding is now supported by all tested Kindle devices and apps. This was not the case just a few short years ago, when Kindle reflowable files did not allow custom fonts. Now they do, and KF8 has supported them from inception, and happily continues to do so. I include it because it's just good to know. And it's always nice to end on a positive note.
CONCLUSION
These are all considerations each ebook designer must weigh and make decisions on, based on their project and target audience. Bear in mind that digital publishing is still in its infancy, and in a state of great upheaval at the moment. All of this will settle out in time, but for now we have to be aware of what is possible and what is not, and try to stay abreast of any changes (which are numerous and often). Already this chart shows the great disparity between a single year's development of the Kindle Fire line: in at least half the features listed there is a difference in functionality between the 1st generation Fire and the latest models.
My biggest issue continues to be the lack of support for live text when either booktype value is entered, making my clear recommendation not to add one. The only functionality that will be lost by doing this are the two instances where Page Spread works with the comic value entered, but not when it is absent - these being the HD7 and Android app - as well as Virtual Panels on the same two readers. But since these features are hardly universal, being not yet present in any other case (aside from the HD9 where Page Spread is functional regardless of booktype), there is very little incentive to add a booktype value. The primary exception, unfortunately, is that only the "comic" booktype allows images of up to 800kb in size; otherwise, you're restricted to 256kb for fixed layouts, which can be a significant consideration with the advent of HD displays. Of course, this may all change (and probably will) over time as new updates are rolled out. But one cannot plan current work based on future possibilities. One must take what data is available today and use it to inform your present efforts.
As mentioned, I will update this chart regularly, and note the changes made at the bottom of the post. If a large number of changes are suddenly made - say, when a new line of devices arrives - I will do a new post and reevaluate the situation.
And by the way, if anyone has a 2nd generation Fire or a Mac with the Kindle desktop app and can test any of these features I would very much appreciate the information. I would love to add it to the chart for reference and will gladly give you ample credit and provide a link, both here and in the published ebook. For that matter, if any of your own testing contradicts what I have listed here, please let me know so I can look into it further. Comment below or send an email to scot(at)fantasycastlebooks.com.
UPDATE 1/6/2013 4:00 P.M.
Just for the sake of being thorough, I went ahead and tested the eInk Kindle 3 and Paperwhite devices. And while I won't bother to include the data in the chart above due to space restrictions, I will point out the primary data points here.
First, and most surprising, is that the Paperwhite actually supports Page-Spread in all booktypes. This is accessed via the menu's "View in Landscape" option, since the Paperwhite has no internal orientation sensor. Just as interesting is the fact that, while the Kindle 3 does not support Page-Spread, it does default to landscape orientation for the booktype values "children" and "none" (though inexplicably showing only one page at a time), while for comics it reverts to portrait orientation. There is no way to change the orientation from the Kindle 3 menu. Letterbox color is white in each instance.
Equally surprising is support for Virtual Panels on the Paperwhite with "comic" or "none" booktypes (but not for children's books). This is, therefore, the only device that currently does so with the booktype absent, and only the second device that supports it at all. Why the eInk Paperwhite would support this function, but not the 1st gen Fire is beyond me (except that the Fire's OS has not been updated for some time).
Another curious fact is that pinch and zoom is available for all pages on the Paperwhite with any booktype setting, regardless of image insertion method. The Kindle 3 has some default zoom functions available via the menu, with incremental 5-way controller scrolling in all directions rather than the Virtual Panels' default quarter page progression. So that's a sort of "qualified" yes for that feature.
Cover issues remain consistent on both devices, and there are no Table of Contents menus in any instance. Bookmarks are functional in all three booktypes on the Paperwhite, but not at all on the Kindle 3, even though it retains the default Bookmark and TOC menu links, they're just grayed out and inactive. There are no live text functions, nor active hyperlinks, on either device in any booktype, but font embedding is consistently present.
January 5, 2013
Kindle Fixed Layout Tutorial - Part 2
WORKING METHODOLOGY
There are two fundamental types of fixed layout ebooks that can be made in Kindle Format 8. Amazon divides these into "Children's" and "Comics" categories, even though this is a rather broad, and often inaccurate, labeling scheme, since any genre, age level, or subject category can be produced in either format. Yet there are significant differences between the two.
The primary difference is that "comics" consists entirely of full-page images, while "children's" ebooks include text laid over the top of background images. Both can include interactive Region Magnification features which, in the case of comics' "Panel View" function enlarges a pre-defined area of the full-page image when tapped, while the children's format includes the ability to magnify text boxes. But, of course, this isn't entirely accurate either, since comics can include text overlays and children's books might include only images.
Still, each has these inherent features for a reason, and each will be discussed and analyzed at the appropriate time. For practical purposes the division suits us here, since there are presumably two essential groups of people reading this tutorial:
Those who want to make simple, image-only ebooks (i.e. comics)
Those who want to create complex layouts reflowable format does not allow (i.e. children's books and other illustrated content)
With this in mind, we will begin by covering all the necessary steps in producing image-based ebooks in Kindle fixed layout format, from start to finish, and then progress to add in layers and region zoom features. In that way everyone can start at the beginning and jump ship when they're project is complete.
As for our plan of attack, a glance at the table of contents will provide a quick outline, but here are the essential steps:
· A look at the necessary Tools, including the Template, which will be our project guide throughout the tutorial
· An overview of the File Structure of a Kindle fixed layout ebook, followed by a look at each of its component parts
· The OPF file, including Metadata, Manifest, Spine, and Guide items
· The NCX file, including Metadata, NavMap, and PageID features
· Creating Images for Kindle fixed layouts, including the Cover
· HTML page layout, including CSS styling for image-only ebooks
· Converting and testing your file using Kindlegen and Previewer
· HTML & CSS for Panel View, including an analysis of Virtual Panels
· HTML & CSS for Text Zoom, including Font embedding
· Tips & Tricks with Zoom functions
Each of these are subdivided into smaller parts, detailing what each one does and what your options are. Some are short and simple, others somewhat long and complex, but all as thorough as they need to be. So with that, let's get started!
January 4, 2013
Kindle Fixed Layout Tutorial - Introduction
The following is the first part of a multi-part tutorial on making fixed layout ebooks specifically for the Kindle that I will be posting over the course of the next few weeks. These comprise the working draft of an ebook on the subject that will be published later this month. I will be posting at least the first portion of the book, up to and including the step-by-step creation of an image-only fixed layout ebook in Kindle format for comic books and graphic novels.
The remaining sections covering the addition of Panel View and Region Zoom functions may or may not be posted here, in part because I have already provided a functional overview of the Region Magnification feature here, and of course because I'd like to get a little compensation for my efforts in the form of ebook sales. However, depending on the feedback I receive I may post some additional sections.
The new tutorial covers every aspect of producing KF8 fixed layout files from start to finish in a step-by-step approach, and also includes links to a newly revised fixed layout template for your use in starting your own project. The published tutorial will also be updated as Amazon adds new functionality to the Kindle platform (such as full audio and video support), with buyers of the ebook receiving free downloads and notification of all future updates.
Posting this here is also something of a beta test. Blogging a book has become an effective - and strategic - practice that allows for author-reader interaction prior to a book's official publication, giving both sides time to work out bugs and polish up the prose, helping to improve the final product. So any feedback you have to offer will be seriously considered and heartily appreciated.
INTRODUCTION
Comics and graphic novels, as well as many illustrated children's books and non-fiction works, contain complex layouts and graphic elements, such as full-bleed images and text wrapping, that require special formatting not available in standard "reflowable" formats. These "reflowable" ebooks allow users to resize text and margins, and even change the font or background color. Conversely, "fixed-layout" content is... well... "fixed," displayed exactly as the ebook creator made it.
And while all those reflowable features are one of the things that make ebooks truly unique, graphic design is an art form, with a long and illustrious history of development. Fixed layouts allow that art to be preserved. This tutorial explains how to create fixed layout ebooks for the Kindle platform. It does not delve into reflowable formatting, nor creating fixed layout files for other platforms such as Nook or iBooks. Kindle ebooks are unique in the way they're made, and in this tutorial you'll learn how that's done.
Fixed layout formatting supports "full-bleed" artwork (i.e. edge-to-edge with no margins), as well as the layering of multiple elements on top of one another, using a basic set of HTML and CSS for styling and placement, as well as a bit of Kindle-specific code for features such as Panel View (Kindle's image zoom feature). You don't need to know very much code to make an ebook work, but, of course, the more you do know, the more complex your design can be. In this tutorial I'll explain all you need to create layouts as simple or complex as you like.
With the introduction of the full-color Kindle Fire e-reader in November of 2011, Amazon also released a new ebook format known as Kindle Format 8, or KF8 for short, as the successor of the preceding Mobi 7 format. KF8 includes many new features, including fixed-layout capability for creating image-heavy ebooks with text overlays, as well as text and image zoom, much of it based on proprietary code that only Kindle apps and devices can read. Initially only the Fire could read KF8, but in recent months the format has been rolled out to nearly all of the Kindle line of apps and devices.
This ebook provides a step-by-step tutorial for producing fixed-layout ebooks formatted for Kindle devices and apps with KF8 support. Only Kindle devices from the third generation forward currently support this format (inc. Kindle Keyboard and Touch, but not Kindle 1 or 2), as well as all updated Kindle apps for PC, Mac and Android, but not for iOS, which currently has support for full-page images, but not text overlays or region zoom. Consequently, fixed-layout Kindle ebooks cannot be read at present on the iPad if they contain layers.
Ironically, the Kindle for iOS app is the only Kindle reader that currently supports audio and video, making it nearly pointless to produce Kindle ebooks with these features at the present time. Therefore, this tutorial does not currently cover those functions, although it will be updated at such time as Amazon decides to make them available on a majority of their devices. For those interested, the Kindle Publishing Guidelines has details on their creation.
The ebook edition of this tutorial uses reflowable formatting, so that all Kindle apps and devices can open it. It has
images placed in between the blocks of text (not behind them), so that they flow
along with the text in any display size. You can make image-only ebooks with
reflowable formatting, but there will be a large white margin around the
outside that will reduce the size of the useable image area. To remove it you
must use fixed layout formatting.
You must decide for yourself if fixed layout or reflowable
is the right choice for your project. In general, if it can be formatted as
reflowable without losing important aspects of the design it probably should
be, since fixed layout removes many features ebook readers like, such as font
resizing. But for image-based ebooks like comics and graphic novels fixed
layout is really the only choice.
January 3, 2013
Tablet Market Share Update
Barnes & Noble today announced a 10.9% drop in retail sales over the 9-week holiday season - due in part to store closures during 2012 - coupled with a 12.6% decline in Nook sales. This was offset somewhat by a 13.1% increase in digital content sales, showing that current Nook at least users continue to use their devices steadily.
But BN were not the only ones who showed a slowdown in device sales. Apple's iPad line performed less well than expected, losing ground to rival tablets, with a 7.14% decline in market share, while the Kindle Fire gained 3.03%. Mind you, this still leaves the iPad with a whopping 78.84% of the tablet market compared to The Kindle Fire's 7.51%, so it's hardly disastrous, if even damaging.
This is the same thing that happened to Amazon ebook market share when other e-reading devices began to appear: the Kindle once held well over 90% of the ebook sales, which is now down to a still-respectable, yet decidedly smaller, 65% or so. The same thing is likely to occur with the iPad as new high-quality (and lower priced) devices hit the shelves.
And bear in mind that these are only tablet stats, and do not include the many other Kindle models such as the Paperwhite and Touch, which are dedicated e-reading devices (i.e. no apps or video). Including those gives Amazon a far larger share of the overall device market, a share that is steadily growing.
What this discrepancy between tablet and ebook sales tells me is that iPad owners do not use their tablets for reading, but Kindle users do. What I wonder is if Amazon's push into the multimedia tablet market is bound to hurt their ebook sales. Probably unlikely, but it does take their focus further away from books, which is the place they started.
The statistics in the chart above are based on data use monitoring, a clever way to see who's using what. New device activations and traffic sampling can tell a lot about what products are actually being used, as opposed to what was bought or given and is just collecting dust. The full chart also contained a section detailing smartphone use, which I've cropped off as not relevant to this blog, but you can click the image above to see the full thing and read a bit more commentary.
Other notes to point out from this information is the serious lack of interest in the Surface, which fared poorer than the Blackberry Playbook that has been written off as all but dead. Admittedly Microsoft's entry into the tablet market is intended for serious professionals only, and is a top notch machine, but it's also priced at a premium level that's way out of the average user's reach, particularly given the rapidly growing competition.
But what surprised me the most was that Samsung's Galaxy Tab is doing so much better than the Nexus. Granted, Samsung has a few years' head start on Google, who have only recently entered the fray. But with consistently rave reviews for the Nexus line I would have thought to see a larger increase. I suppose it just goes to show how tightly Apple has this thing locked up - even though they've lost a little ground, they're still the uncontested champs, and will be for some time to come.
January 2, 2013
Tablet & e-Reader Display Resolution
Here's a quick comparison chart I put together showing the display resolution and aspect ratios of most of the major tablets and e-reading devices currently on the market, or generally still in use. It is not exhaustive, but it covers the primary reading devices being used by the majority of ebook readers, and consequently is a useful reference for making decisions regarding ebook formatting (the reason I compiled it in the first place).
I just thought I'd share it, since the information isn't readily available in one place - at least not without having to sort through a lot of useless information that's not relevant - and most tech specs neglect to include pixels-per-inch and aspect ratio as part of their breakdown. These are handy to know when you're preparing cover art or internal illustrations, particularly for fixed layout ebooks aimed at a target market or platform.
DEVICE
Resolution
Pixels
Aspect
KINDLE E-INK
800 x 600
167 ppi
4:3
KINDLE PAPERWHITE
1024 x 758
212 ppi
4:3 *
KINDLE FIRE
1024 x 600
169 ppi
10:6 **
KINDLE FIRE HD 7"
1280 x 800
216 ppi
16:10
KINDLE FIRE HD 8.9"
1920 x 1200
254 ppi
16:10
NOOK
800 x 600
167 ppi
4:3
NOOK COLOR/TABLET
1024 x 600
169 ppi
16:10
NOOK HD 7"
1440 x 900
243 ppi
16:10
NOOK HD+ 9"
1920 x 1280
256 ppi
3:2
KOBO MINI [5"]
800 x 600
200 ppi
4:3
KOBO TOUCH [6"]
800 x 600
167 ppi
4:3
KOBO GLO [6"]
1024 x 758
213 ppi
4:3 *
KOBO VOX [7"]
1024 x 600
169 ppi
10:6 **
KOBO ARC [7"]
1280 x 800
215 ppi
16:10
IPAD 2 [9.7"]
1024 x 768
132 ppi
4:3
IPAD 3 & 4 [9.7"]
2048 x 1536
264 ppi
4:3
IPAD MINI [7.9"]
1024 x 768
163 ppi
4:3
MOTOROLA XOOM 8.2"
1280 x 800
184 ppi
16:10
MOTOROLA XOOM 10.1"
1280 x 800
149 ppi
16:10
GALAXY TAB 7"
1024 x 600
171 ppi
10:6 **
GALAXY TAB 8.9"
1280 x 800
169 ppi
16:10
GALAXY TAB 10.1"
1280 x 800
149 ppi
16:10
NEXUS 7"
1280 x 800
216 ppi
16:10
NEXUS 10"
2560 x 1600
300 ppi
16:10
SURFACE RT [10.6"]
1366 x 768
148 ppi
16:9
SURFACE PRO [10.6"]
1920 x 1080
224 ppi
16:9
* 10 pixels narrower than full 4:3 ratio
** Actual ratio is 128:75 = 10.24:6 - or 16:9.375 (i.e. 17:10)
As you can see the aspect ratios fall primarily into two categories - 4:3 and 16:10 - with a few peculiar discrepancies, particularly 10:6 on some common 7" devices. This is remarkably - and almost frighteningly - equivalent to the pan-and-scan / widescreen fight that went on for several years in the video industry (and is still continuing to some degree), and is, in fact, partially due to it, since the primary reason these multimedia devices have begun to appear in widescreen formats is to accommodate accurate video presentation.
However, a print book's natural aspect ratio is akin to old tube television's 4:3 standard, and so a comparative digital two-page spread fits nicely on an iPad but is miserably represented on the 10:6/16:10 devices. And since ebooks and print books will very likely continue to coexist for many years to come (and thus ebooks will naturally continue to emulate their printed counterparts, especially where fixed layout is concerned) my preference would be for the 4:3 format to triumph over widescreen (ironically opposite to my desires for film all those years I worked in the video industry), since black letterboxing is less intrusive to video than the relative shrinking of a book page, which in many cases renders it illegible. The fact that people are (surprisingly) will to watch videos on their tiny 5" iPhones just goes to show it's nowhere near as critical as the legibility of text.
As a minor side note, I find it ironic that no other major tablet brand has gone after the iPad's 4:3 ratio for one of their larger multimedia devices. Intentionally avoiding a head-to-head confrontation where Apple dominates the market, or merely a different focus?
At any rate, I hope you find the data useful. I'll try to keep the chart updated, so bookmark this page for future reference.
I just thought I'd share it, since the information isn't readily available in one place - at least not without having to sort through a lot of useless information that's not relevant - and most tech specs neglect to include pixels-per-inch and aspect ratio as part of their breakdown. These are handy to know when you're preparing cover art or internal illustrations, particularly for fixed layout ebooks aimed at a target market or platform.
DEVICE
Resolution
Pixels
Aspect
KINDLE E-INK
800 x 600
167 ppi
4:3
KINDLE PAPERWHITE
1024 x 758
212 ppi
4:3 *
KINDLE FIRE
1024 x 600
169 ppi
10:6 **
KINDLE FIRE HD 7"
1280 x 800
216 ppi
16:10
KINDLE FIRE HD 8.9"
1920 x 1200
254 ppi
16:10
NOOK
800 x 600
167 ppi
4:3
NOOK COLOR/TABLET
1024 x 600
169 ppi
16:10
NOOK HD 7"
1440 x 900
243 ppi
16:10
NOOK HD+ 9"
1920 x 1280
256 ppi
3:2
KOBO MINI [5"]
800 x 600
200 ppi
4:3
KOBO TOUCH [6"]
800 x 600
167 ppi
4:3
KOBO GLO [6"]
1024 x 758
213 ppi
4:3 *
KOBO VOX [7"]
1024 x 600
169 ppi
10:6 **
KOBO ARC [7"]
1280 x 800
215 ppi
16:10
IPAD 2 [9.7"]
1024 x 768
132 ppi
4:3
IPAD 3 & 4 [9.7"]
2048 x 1536
264 ppi
4:3
IPAD MINI [7.9"]
1024 x 768
163 ppi
4:3
MOTOROLA XOOM 8.2"
1280 x 800
184 ppi
16:10
MOTOROLA XOOM 10.1"
1280 x 800
149 ppi
16:10
GALAXY TAB 7"
1024 x 600
171 ppi
10:6 **
GALAXY TAB 8.9"
1280 x 800
169 ppi
16:10
GALAXY TAB 10.1"
1280 x 800
149 ppi
16:10
NEXUS 7"
1280 x 800
216 ppi
16:10
NEXUS 10"
2560 x 1600
300 ppi
16:10
SURFACE RT [10.6"]
1366 x 768
148 ppi
16:9
SURFACE PRO [10.6"]
1920 x 1080
224 ppi
16:9
* 10 pixels narrower than full 4:3 ratio
** Actual ratio is 128:75 = 10.24:6 - or 16:9.375 (i.e. 17:10)
As you can see the aspect ratios fall primarily into two categories - 4:3 and 16:10 - with a few peculiar discrepancies, particularly 10:6 on some common 7" devices. This is remarkably - and almost frighteningly - equivalent to the pan-and-scan / widescreen fight that went on for several years in the video industry (and is still continuing to some degree), and is, in fact, partially due to it, since the primary reason these multimedia devices have begun to appear in widescreen formats is to accommodate accurate video presentation.
However, a print book's natural aspect ratio is akin to old tube television's 4:3 standard, and so a comparative digital two-page spread fits nicely on an iPad but is miserably represented on the 10:6/16:10 devices. And since ebooks and print books will very likely continue to coexist for many years to come (and thus ebooks will naturally continue to emulate their printed counterparts, especially where fixed layout is concerned) my preference would be for the 4:3 format to triumph over widescreen (ironically opposite to my desires for film all those years I worked in the video industry), since black letterboxing is less intrusive to video than the relative shrinking of a book page, which in many cases renders it illegible. The fact that people are (surprisingly) will to watch videos on their tiny 5" iPhones just goes to show it's nowhere near as critical as the legibility of text.
As a minor side note, I find it ironic that no other major tablet brand has gone after the iPad's 4:3 ratio for one of their larger multimedia devices. Intentionally avoiding a head-to-head confrontation where Apple dominates the market, or merely a different focus?
At any rate, I hope you find the data useful. I'll try to keep the chart updated, so bookmark this page for future reference.
The Kindle Paperwhite - A Semi-Review
Kindle Paperwhite Exploded View
There's a cool article over at the NYTimes detailing how the Kindle Paperwhite works, with this nifty graphic showing an exploded view of its contents. Hit the link to see it with the text overlays that explain what each piece does. It's amazing what they can cram in there these days.
I bought a Paperwhite a few months ago, mostly for format testing, but also because I love the longer battery life of the eInk screens, which means I don't need to take a charger with me when I travel. Unfortunately it was a big step down from the brightly lit, full color Kindle Fire, with its crisp, smooth letters and high contrast. By comparison the Paperwhite is dull and gray, making the words appear washed out, even though it has the best eInk screen to date, with a higher resolution than an iPad 2 or Mini. But sixteen shades of gray is still all that you get, which is a long way from fifty.
The main thing I dislike about the Paperwhite is its sluggish response, with a maddeningly slow refresh rate compared to LCD, which is nearly instantaneous. By comparison the Paperwhite seems to take forever to respond, even though it's miles ahead of earlier eInk devices - 450 mSecs, compared to 600 mSecs for the older models (i.e. 25% faster). Yet given that a color eInk display capable of video refresh rates was announced in November, even half a second for one transition is glacially slow (video refresh needs at least ten times that to approach the standard 24fps).
Video-Capable 6" Color eInk Prototype
Of course, one major stumbling block that Amazon faces is the cost of production, with component parts making up the bulk of the cost. Given the current tablet battle, price point can be a far more important stat than cutting edge performance. This is why we get incremental upgrades. It's also very often a question of compromise between higher resolution and faster processing speed, since more pixels require more processing power, which drains more battery life and costs more to produce.
Readers of this blog will know that I'm a big advocate of color displays, which reproduce cover art and hyperlink colors that even text-based novels include, not to mention on-device bookstore browsing, which is an abysmal process on a black and white device. Just imagine going into a physical bookstore and only seeing black and white on all the shelves. You would think that Amazon would want to add color as soon as possible, simply as a marketing strategy. But all good things in time. One day this will be a mute point.
The Not So Easy to Reach the Menu
The other thing that throws me constantly when using the Paperwhite is the placement of the tap zones, which I find irritating beyond belief. I wrote a post about this back when Amazon first introduced this "new improved" zone layout, which made no sense to me in theory, and is worse in practice. I'm so used to tapping the center of a touch screen to access the menu that I'm constantly turning the page on the Paperwhite instead. Who thought up this nonsense? Off with their heads!
On the good side, the new front light is a handy feature, rendering the display illumination more or less consistent in any light, from direct daylight to pitch black. Given that the screen looks washed out most of the time this isn't a raving endorsement, but at least it looks washed out consistently. And it's also really light, weight-wise, making it much more pleasurable to hold for long spells than any LCD reader I own (three Fires, two iPads and a Nook tablet), aside from my Motorola Razr Maxx (which is a full two ounces lighter).
Interestingly, I thought that I would love the new "Time To Read" feature, which calculates the time remaining in a chapter or the whole book rather than showing the number of pages left. This is continuously calculated from your actual page turn progress, and so theoretically gets more accurate the more your read. However, I find that it causes me to be more aware of how fast I'm reading than what I'm reading. Perhaps I'll start to ignore it over time, but I often stop to ponder over certain passages, and tend to re-read lines and phrases that I either want to absorb more thoroughly (in the case of non-fiction), or simply enjoyed (primarily with fiction, but a well turned phrase or deeply moving thought is never out of place); the "Time To Read" feature often interrupts those moments with a jarring "Oh crap! I should be reading!!!" But then, maybe that's a good thing. I probably should be reading, after all.
And since eInk only uses battery power to turn the page (as long as the new front light is turned off, that is), I often just set down the device when I pause to answer the phone or get a drink, leaving the reader on. Eventually the screen times out and the splash screen wallpaper appears, but all that time is now added to my reading speed, making it highly inaccurate and rendering the feature useless. Again, it's something I can remedy by retraining myself to turn the darn thing off, but at best that's an unnecessary inconvenience that I never had to worry about before, and at worst I'll still forget most of the time. But I suppose that's just the nature of the times we live in.
December 31, 2012
Smashwords Now Accepting EPUBs
According to a site update yesterday, the self-publishing aggregator portal Smashwords is now accepting ePub files in preparation for the launch of Smashwords Direct, allowing ebook formatters to bypass their Meatgrinder conversion tool and upload a finished file for direct distribution to retail outlets. In theory, this will finally allow for complex formatting such as fixed layouts and floating sidebars that the Word .doc based ingestion system did not support. However, the details are still a little thin.
Here's the official statement:
December 30, 2012 - (Updated) We're preparing to launch Smashwords Direct, our direct .epub upload option. One year ago in my 2011 annual year-in-review over at the Smashwords Blog, we made a commitment to launch SWD in the second half of 2012. We're working to fulfill that commitment. We're nearing the beta launch of SWD. The first iteration will enable those of you with professionally designed .epub files to replace your current Smashwords-generated .epub with another .epub. It'll also allow authors to upload .epub files instead of Word .doc files. Thank you to all the Smashwords authors who provided .epub files for our internal testing. Update: As of earlier today, you may now upload an EPUB to supplement your DOC-based book (replacing its EPUB with your own), as well as create new books using only an EPUB. (Note: We do not currently produce sample files, online HTML reader content, or other ebook formats based on EPUBs.)
Unfortunately, this is as much information as is given, and the formatting guide and FAQ have not yet been updated, so the details are unclear. For example, does the Smashwords ePub ingestion engine handle fixed layout ePubs formatted specifically for iBooks, or only those based on the ePub standard? Will ePub3 compliant files be supported, recommended, or required? For now it seems your only option is to upload a file and see what happens. But at least this is a step in the right direction. Post and let me know if you've given this a try.
