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.
No comments have been added yet.
