View Cart

Kindle Fixed Layout Functionality Chart

The following chart comprises Appendix A of the formatting guidebook How To Make Kindle Comics & Children's Books. The information is discussed thoroughly and referred to throughout the book, but having it here as reference might be helpful, as keeping an online version updated is much quicker and more efficient than revising the published manual.

As discussed in the metadata section of this tutorial, the Kindle format contains one unusual entry in the OPF that is unlike any other, in that it effects a broad range of changes to an ebook’s functionality (rather than determining a single attribute, such as orientation, for example), none of which is detailed by Amazon in their documentation. Hence, this chart.

This element is the “book-type” entity, which has as valid entries the “comic” or “children” values, according to the Kindle Publishing Guidelines. In addition, a third “book-type” is effectively created by simply leaving out the entry or entering a value of “none”, which in many cases produces different results than adding either of the other values. Each of these creates a set a variables that enable or disable various elements of Kindle fixed layout functionality, and consequently changes the way many fundamental aspects of the ebook work, some more or less important than others, depending on the project and your personal preferences. Over the years many of these (and other) issues have been eliminated, or minimalized, but many still remain. A few new ones have also cropped up.

The data given in the chart below provides a breakdown of these functions for each book-type value across a range of Kindle devices and apps, so that you can determine which setting is best for each project. The data is discussed in further detail below the chart, along with a description of what each “function” entails, since some of them are not at first glance obvious.

Some of these have been discussed either in the online tutorial or in the body of my published manual, while others have not been mentioned elsewhere. Footnotes in the table provide more detailed explanations of the data where the entries are conflicting or have specific conditions for their use, as when the results change based on another variable, which has become increasingly the case with the last few updates to the Kindle operating system.

Each of the rows in the table features one functionality element in KF8 that has been tested on the devices and apps listed in the columns to the right, with each of the three book-types given in the column to the left.

As a final note to this prologue, I would state that issues #2, 6, and 8 are the most critically hampered at present (these being two page spreads and live text functions, plus the absent menu link in three cases), with #s 3, 7, and 9 needing serious attention. The rest are generally minor nuisances of more or less significance depending on your preferences (I'm a strong advocate for #4 due to some particular uses I make of it). Lastly, #10 has been a lost cause from day one, and would fall under the "critically hampered" category if it worked correctly on more than one device. As it stands, it's a non-functioning function.

[UPDATED 9-1-15]

Change Log:

iOS UPDATE: I decided to test the Kindle of iOS app again, since I haven't done it for awhile, and I was planning to update the chart for the published manual in both print and ebook, so it seemed a good time to do so. As it turns out, the .azk file now functions correctly (for the most part) as a full-bleed fixed layout in Kindle for iOS when transferred via iTunes, and to varying degrees even RegionMag content is functioning (albeit with some very peculiar behavior in the mag regions which I discuss in the notes below). Layered elements are generally sized and positioned correctly (aside from some errors in Mag Regions), but in no case is live text active, though curiously both internal and external hyperlinks still work correctly. Moreover, the "page-id" element functions properly with correct inner margins in most instances, though not all. Further, pinch-and-zoom is available for ebooks with no RegionMag code present, but are locked down otherwise. Bookmarks are not available in any case. Since many of the functions detailed on this chart are now present (and can be tested) in the iOS app, I have added a new column to denote its features, and will add it to my battery of tests henceforth.

[UPDATED 8-28-15]

Change Log:

1 - Letterbox Color is now black on the PC App for all book-types, as well as for the Android App with the "comic" book-type.
2 - Page-Spreads now work on the PC App with "comic" book-types when no RegionMag is present, but no longer work on the HD8.9 when no book-type is entered, as it used to, or on that device with the "comic" book-type entered and RegionMag present (as noted in 3*). A further note has been added regarding errant rendering of final pages in comics on the Paperwhite (Note 4a), as well as one regarding a new error in the "page-spread" spine value with the "children" book-type entered (Note 4b).
3 - Virtual Panels do not work for single final pages of ebooks with the "comic" book-type value on the Paperwhite (Note 5*). I have also added two peripherally related notes here regarding RegionMag on the Paperwhite, which has developed some layout issue with regard to zoomed regions. See notes 5b and 5c as well as the commentary below. If this keeps up I'll have to add a new row for Region Magnification issues, but at present it's confined to the Paperwhite.
6 - TOC Menu Link is still missing in children's ebooks on the HD devices and the 2nd generation Fire, where I had noted it as having been fixed previously. This was due to an error in one of my test files, where I had erroneously entered "childrens" for the book-type rather than "children" (no s), which Kindlegen regards as the same as "none" (any book-type value entered other than "children" or "comic" is a null value). Thus, unfortunately, the TOC menu is, in fact, still completely absent from the devices mentioned. There is no access to a device menu TOC at all, and thus, no navigation without a practical table of contents included (aside from the scrubber bar). This is includes the "Search" icon, which is also missing.
7 - Bookmarks are now working in the PC app for the first time, but in the exact opposite circumstances as the Android app; i.e. the presence or absence of RegionMag code, as specified in Note 12a/12b.
8 - Live Text Functions / 9 - Hyperlinks have developed an alignment error on the Kindle for PC app, for which I have added a new Note 13.
10 - Layout Blank now functions as expected in all cases on the Paperwhite (the comic book-type did not work correctly before), and for the first time on both tested apps and the Fire 2nd Gen and HD models, but only when no RegionMag is present in the publication. However, neither app will now display layout-blank pages at all in any other instance, although they used to (albeit incorrectly). Further, while the HD8.9 used to work as intended with either the comic or no book-type values entered, now it doesn't work at all except in the one instance specified above. In the iOS app it works correctly when no book-type is entered, but otherwise only if RegionMag is present. Note that this correlates precisely with the functionality of the page-spread feature. Overall, this is a net gain for comics, but a loss or status quo elsewhere.

Further details have been added in the relevant commentary sections below the chart.

I've also added a line near the top of the chart giving the latest version of the OS tested on each platform for reference, rather than just providing the date of my latest round of tests. I still can't justify buying either of the HDX devices, or the Fire HD 6" for that matter, so those are not yet tested. I also won't pursue the eInk platform further until it supports full color, as it's just not conducive to fixed layouts in most cases otherwise.

Function
Booktype
PC App Android
App
Paperwhite
(1st Gen)
Fire
(1st Gen)
Fire
(2nd Gen)
Fire HD7
(1st Gen)
Fire HD8.9
(1st Gen)
Kindle
for iOS
Latest Version Tested: 1.12.2 4.15.0.48 5.6.1.1 6.3.4 10.5.1 7.5.1 8.5.1 4.10
1 - Letterbox Color
Comic
Children
None

Black
Black
Black

Black [1]
White
White

White
White
White

White
White
White

Black
White
White

Black
White
White

Black
White
White

White
White
White
2 - Page-Spread
Comic
Children
None

Y/N [2]
No
No

Y/N [3]
No
No

Yes [4(a)]
Yes [4(b)]
Yes [4]

No
No
No

Y/N [3]
No
No

Y/N [3]
No
No

Y/N [3]*
No
No

Y/N [i]
Y/N [i]
Yes
3 - Virtual Panels
Comic
Children
None

No
No
No

Y/N [5]
No
No

Y/N [5]*[5b]
No [5c]
Y/N [5]

No
No
No

Y/N [5]
No
No

Y/N [5]
No
No

Y/N [5]
No
No

No [ii]
No [ii]
No [iv]
4 - HTML Image Zoom
Comic
Children
None

No
No
No

No [6]
Yes
Yes

No [7]
No [7]
No [7]

No
Yes
Yes

No [6]
Yes
Yes

No [6]
Yes
Yes

No [6]
Yes
Yes

No [ii]
No [ii]
No [v]
5 - HTML Cover Doubling
Comic
Children
None
[8]
Y/N
Y/N
Y/N
[8]
Y/N
Y/N
Y/N
[8]
Y/N
Y/N
Y/N
[8]
Y/N
Y/N
Y/N
[8]
Y/N
Y/N
Y/N
[8]
Y/N
Y/N
Y/N
[8]
Y/N
Y/N
Y/N

N/A
N/A
N/A
6 - TOC Menu Link
Comic
Children
None

Yes
Yes
Yes

Yes
Yes
Yes

Yes
Yes
Yes

Yes [9]
Yes [9]
Yes [9]

Yes [10]
-NO-[!!!]
Yes [11]

Yes [10]
-NO-[!!!]
Yes [11]

Yes [10]
-NO-[!!!]
Yes [11]

Yes
Yes
Yes
7 - Bookmarks
Comic
Children
None

Y/N [12a]
Yes
Yes

Y/N [12b]
No
Yes

Yes
Yes
Yes

No
No
Yes

No
No
Yes

No
No
Yes

No
No
Yes

No
No
No
8 - Live Text Functions
Comic
Children
None

Yes [13]
Yes [13]
Yes [13]

No
No
Yes

No
No
No

No
No
Yes

No
No
Yes

No
No
Yes

No
No
Yes

No
No
No
9 - Hyperlinks
Comic
Children
None

Yes [13]
Yes [13]
Yes [13]

Yes
Yes
Yes

No
No
No

Yes
Yes
Yes

Y/N [14]
Yes
Yes

Y/N [14]
Yes
Yes

Y/N [14]
Yes
Yes

Yes
Yes
Yes
10 - Layout-Blank
Comic
Children
None
[15]
Y/N
X
X
[15]
Y/N
X
X
[15]
L
L
L
[15]
P+L
P+L
P+L
[15]
Y/N
X
X
[15]
Y/N
X
X
[15]
Y/N
X
X

L/X [iii]
L/X [iii]
L

[1] Now black all the time, regardless of RegionMag presence, whereas it was variable before.
[2] Yes when RegionMag is absent, No otherwise. Working page spreads have correct inner margins based on the Spine property value. The latter is the one and only case where the page-spread toggle button in the PC app is functional in fixed layouts.
[3] Yes when RegionMag is absent, No otherwise. All page spreads have inner margin removed, regardless of Spine property value. *Was functioning correctly on the HD8.9 with RegionMag present until recent updates, but page spread functionality has been disabled in this case.
[4] Page spreads now work for the "comic" and "none" book-types on the Paperwhite, with correct inner margins, but the "children" book-type has some issues (see Note (b) below).
(a) Single final pages on the Paperwhite are stretched to two-page width.
(b) While "facing-page" spreads function correctly, "page-spread" layouts no longer do, adding an oversized margin between the pages that pushes the left page halfway off the screen.
[5] Virtual Panels active only when RegionMag code is absent. *Single final pages on the Paperwhite do not work.
[5b] Zoomed RegionMag panels in comics on the Paperwhite no longer respect coded size and positioning information, but magnify all MagTarget panels to full screen. This throws any complex layout formatting completely out of whack (such as text layers inside magnified regions, for example, which work elsewhere). See further details in the Virtual Panels section below.
[5c] Tap Target size and position values for Region Magnification are no longer respected. Tapping anywhere on a page that contains mag regions activates them. If more than one exists on the same page, the targets are activated more or less at random, regardless of where you tap, even on top of another active target area. The last Tap Target on the page cannot be activated at all, except by swiping to it from ones above.
[6] HTML Image Zoom does not work, but Pinch & Zoom is available when Virtual Panels are active (i.e. when RegionMag is absent). Zoom and shrink limits are imposed in this case, so that the image cannot be magnified beyond its actual size, nor smaller than the display size, whereas with HTML image zoom you can exceed these limits. However, when RegionMag is present all images are locked, regardless of insertion method, and cannot be zoomed where magnification regions are not provided.
[7] Double-Tapping does not work, but Pinch & Zoom is available for all pages except the final one, without tapping, regardless of image insertion method. Final pages have no functionality whatsoever.
[8] Yes when NAV is present, No otherwise, as the HTML cover page is then suppressed by KindleGen. The suppress action does not occur in Kindlegen when a NAV is included. Note that an HTML cover page is now strongly dissuaded by Amazon (see commentary on this note below).
[9] Only the Cover, TOC, and Beginning links are present in the device menu. No additional navigation is available from the menu, regardless of what is included in the navigation docs (whether NAV or NCX).
[10] Go To option is available on either the top or bottom menu, depending inexplicably on whether RegionMag code is present, but this takes you to a full Table of Contents menu, with embedded levels. Why the location of the menu link should change in this case is beyond me.
[!!!]The entire menu is absent, so no navigation links are available at all.
[11] Bottom menu contains Search option, while a top menu contains an inactive Settings icon, but functioning Go To, Notes, and Bookmark options. TOC is active on the Go To menu.
[12a] Bookmarks available only when RegionMag code is present.
[12b] Bookmarks available only when RegionMag code is absent.
[13] Technically works, but does not function correctly, as the highlights do not line up with the text beneath. Live text, Mag Regions, and hyperlinks all have the same problem on the PC app, with tap targets not aligned correctly with the content underneath, rendering them essentially useless. This applies to both internal and external links, making practical Table of Contents pages ineffective, as the links will take you to the wrong page.
[14] Both internal and external links are active only when MagRegion is present. Otherwise they are non-functional.
[15] L : Appears in Landscape mode.
P : Appears in Portrait mode.
X : Page does not appear at all, and is not even accessible from a menu link if one is added in the nav docs.
Y/N : Page does not appear at all when RegionMag is present, but works correctly otherwise. This currently corresponds to the Page-Spread functionality as detailed under Notes 2 and 3 above, and provides the only instances in which this functions as intended.
Variations no longer present (at least for now):
** : Page does not appear in either mode, but can be accessed via a menu link when in landscape mode [This is no longer possible].
! : In both orientations the page is visible when scrolling forward, but after scrolling two or more pages forward and then scanning back again the page is absent; if only one page forward has been turned the page is still present when scrolling back. There is an extended pause as the system tries to determine whether to render or bypass the page. [This was previously an Android app error, but appears to have been "fixed" by removing the layout-blank item altogether]

iOS App Notes:
[i] Page-spreads work correctly when RegionMag is present, and correctly for paired pages (either facing or connected spreads) when RegionMag is absent, but in the latter case single pages are incorrectly combined into facing page spreads if there is a page a for it to pair with [see Note iii on Layout-Blank]. Page-spreads only work correctly with or without RegionMag when no book-type is entered.
[ii] Virtual Panels are never present in any case, but if RegionMag is absent all pages can be magnified by double-tapping or via pinch-and-zoom, regardless of the image insertion method (i.e. it functions in the same manner as an iBooks title). With RegionMag present the pages are locked and cannot be zoomed except where Mag Regions are provided. Note, however, that the Tap Targets can be activated by tapping areas outside of the intended target, which can cause somewhat erratic behavior where multiple targets are provided (though tapping in the intended area generally results in the intended function). Moreover, there are a host of things that do not work correctly within the magnified region (or at least not as they do on Kindle devices). These include additional text formatting within the magnified target not being honored (i.e. changing the color of the zoomed text), images inserted via <img src> directly into mag divs not being sized correctly (though CSS referenced images are), and underlying tap target content not disappearing as it should, causing the unmagnified content to show through overlaid Mag Regions with transparent or semi-transparent backgrounds (this does not always occur, though I have yet to determine the differentiating factor).
[iii] Works correctly when RegionMag is present, but page does not appear when RegionMag is absent. Moreover, a "facing-page-left" page intended to be paired with the "layout-blank" page will become the right half of a page spread with a single page preceding it in this instance. Only when no book-type is entered does the "layout-blank" function properly, regardless of whether RegionMag is present or not.
[iv] RegionMag does not work when no book-type is entered.
[v] Double-tapping does not work, but you can still pinch-and-zoom the page.



1. Letterbox Color

This refers to the color used to fill in any display space outside the page content area, much like the “letterboxing” used in widescreen movies on a 4:3 format television (or iPad). This is a minor issue, but one that has perplexed many Kindle content creators, who sometimes find a black fill and sometimes white.

As it turns out, the background is black on the 2nd generation Fire and the two new HD devices when the “comic” book-type is chosen, and white at all other times, with the single peculiar exception of the Kindle for Android app, which has black fill when RegionMag is present, but white otherwise [UPDATE: it is now black all the time]. In addition, the Kindle for PC app shows active menu options (under "View > Color Mode") for the three standard values of white, sepia, or black as offered in reflowable ebooks, but it cannot, in fact, be changed from black.

Given that it is the newest of the Kindle line that sport the black background, this may be an indication of future changes. Not critical in any case, but interesting nonetheless.

2. Page Spread

One of the newer functions 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 not at all consistently true, and even where it functions, it does so in unexpected ways, not at all as described in the Guidelines.

With only a few exceptions, for example, two page spreads are only functional when the “comic” book-type is entered, and in most cases they are presented with no inner margin, even when the “facing-page” property is entered. Moreover, in nearly all instances, page spreads only appear when there is no region magnification code present in the ebook.

Bear in mind that this does not mean a value of “false” is entered for the “region-magnification” metadata value, but that there is no actual code entered anywhere in the publication. The “region-magnification” entry is itself no longer valid, as Kindlegen determines this value for itself by analyzing the content of the files. We’ll discuss this more in a moment when we look at Virtual Panels.

Thus, with just a few exceptions [now only on the Paperwhite], two page spreads are only available in comics with no "Panel View" (RegionMag) functions present. In nearly all other cases only one page is shown at a time in landscape mode, regardless of the “page-id” Spine property. Even the Kindle for PC app, which shows an activated two-page button icon, does not actually display two page spreads [UPDATE: the page-spread button is now active and working correctly in the PC app, so long as no RegionMag code is present, as detailed in Note 2 above].

Incidentally, this has been tested with the orientation-lock property in the metadata set both to "landscape" and "none" for auto-orientation. It made no difference in any case, but had to be tested just the same.

One surprising fact here is that the Paperwhite - the device that least deserves it - actually supports Page-Spread in all book-types (though not correctly for the "children" book-type, as discussed in Note 4b above). This is accessed via the menu’s “View in Landscape” option (which then changes to “View in Portrait”), since the Paperwhite has no internal orientation sensor. As stated in the footnotes above, the Paperwhite has also developed a layout issue with regard to the "page-spread" value of the Spine property, which causes it to now insert an oversized inner margin where there should be none at all. This forces the left page well over halfway off the screen. Page spreads with the "facing-page" value work correctly, with the standard small margin inserted between the pages. Single page layouts work as well.

3. Virtual Panels

This feature is apparently a fallback for fixed layout ebooks that have no custom region magnification elements included, and is active under virtually the same conditions as Page-Spread.

Virtual Panels works by dividing the page into equal segments (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). In portrait mode the page is divided into four quadrants, while in two page spreads each page gets three equal vertical divisions for an overall six-panel layout. On the Paperwhite two-page spreads are only dividing into two halves for each page. A further quirk occurs with single landscape-shaped pages with the orientation-lock turned on, in which case the page is treated as if it were a single portrait-shaped page, with three vertical divisions running down the center, but none for either of the outer edges!

Surprisingly, the magnified page can also 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).

Unfortunately, this is somewhat negated by the fact that, at least for page spreads in landscape orientation, this does not always work as intended, since the auto-created regions do not always cover the full page width, but only span a column down the center of each page. Single pages in landscape are treated as two page spreads, divided into six half page sections in two columns, which is essentially useless. Moreover, the behavior is erratic, as scrolling a zoomed page around often caused the Virtual Panel to take over, moving the page away from the area you were trying to zoom in on.

As with Page-Spread functionality, Virtual Panels is dependent on the complete absence of RegionMag code in the ebook: if any is present, the Virtual Panels features are inactive. And as already mentioned, the “region-magnification” metadata value is entirely irrelevant here (even though the Guidelines still describe it as enabling the Virtual Panel and Text Pop-Up features), since if there are any pages containing RegionMag code, KindleGen sets this value to “true” even if the metadata value you entered is “false”.

In fact, the metadata entry can be completely absent and KindleGen will still enter a region-mag value of “true” if the code is present anywhere in the publication. Conversely, no region-mag value will be added during conversion if no code is present, even if the metadata value is set as “true”. Here is the KindleGen readout for the region-mag value being added:

...while this is what happens when KindleGen ignores the RegionMagnification value:

Notice that the “I1047” entry is entirely absent. It is also interesting that this is handled separately from the other metadata values, which occur before the parsing of the page files, while region-mag now happens after, and apparently as a result of the parsing the page contents.

The Virtual Panels feature is only available on the Android app, the Paperwhite, and the newest Kindle Fire models, and again, in most cases, only when the “comic” book-type value is entered.

For an additional difficulty with Virtual Panels, see number 9. Hyperlinks below.

UPDATE: A few new issues have arisen on the Paperwhite, as noted on the chart above under footnotes 5b and 5c. These are not a Virtual Panels issue, but rather a RegionMag issue, but as I have no entry in the chart for specific region magnification issues, this seemed the best place to make note of it, as it is peripherally related to panel zoom functions.

As stated in the footnotes, the Paperwhite no longer honors any size or position information in magTargets when the comic book-type value is chosen. This is not a simple CSS issue, as other formatting is still present, such as text color and background fills. But all size information is disregarded now in favor of full-page magTarget zooming. This causes all kinds of wonky behavior if you're using complex text layouts within your target regions, such as rotated text. Moreover, if your text happens to be white or light colored against a dark background image it will all but disappear against the white background that appears behind the magnified region, since the full page background now completely disappears as well when RegionMag is activated!

Finally, as stated in Note 5c above, active tap areas are no longer confined to the values given in the CSS, but rather tapping anywhere on the screen activates a pop-up, which is generally the first one, though not always, and is almost never the one you actually tap on! Further, you cannot activate the last target area on a page directly, but must swipe through to it from another one that has been activated. Swiping still works in correct sequential order, so it doesn't seem to be an issue with the ordinals not being recognized. However, given the poor graphics and slow transitions of the eInk display this is not a feature I recommend any reader use on that device, even were it working properly.

4. HTML Image Zoom

This relates to the HTML <img src> insertion method for adding background images in fixed layout (as opposed to the <div id> method of referencing a CSS background-image url), which allows you to magnify the background image by double-tapping on it, and then using pinch-and-zoom to scale and scroll around the image, which until Virtual Panels was the only way this could be done.

Because both this and Virtual Panels are activated by double-tapping on the image, only one or the other can be present at the same time, although as usual the Paperwhite is something of an exception to this rule. In nearly all instances, however, the HTML image zoom function works (since Virtual Panels works in so few).

One further aspect of this issue, however, is not about its functionality, but the use of one image embedding method or the other. Amazon in general recommends the latter, but contradicts themselves at almost every point, including in their own ebook and code examples, where they use the <img src> method almost exclusively, against their own advice.

In fact, Section 4.2.3 of the Guidelines states that the <div id> method is a requirement, because “HTML images interfere with Region Magnification,” which is demonstrably untrue. The crucial point to make here is that Amazon’s “requirement” is non-existent. If you open up a file produced by Kindle Comic Creator you will see nothing but <img src> embedding.

An important distinction to make between Virtual Panels and the HTML <img src> zoom method is that that latter only magnifies the actual background image (which may sometimes be 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. Having the additional option of image embedding methods may prove advantageous, depending on your projects (imagine, for example, an image overlay showing a sad face, while underneath on the background image is a happy one, which appears when the background is double-tapped and the overlay disappears; this is one way to create interactive images when no scripting is available). I demonstrate several examples of this in my Kindle FXL Advanced Template.

As an addendum to the image zoom issue, it should be noted that while the chart above shows "No" to HTML Image Zoom on the Kindle for PC app, page zoom is available from the View > Zoom menu option, or by using the keyboard shortcuts. But technically you cannot click and zoom and image, so the entry value given is still "No".

5. HTML Cover Doubling

This is another example of Amazon giving content creators conflicting information. In Section 4.3.7 of the Kindle Publishing Guidelines (the Fixed Layout Children’s Books section) the 7th Recommendation is that an HTML page containing the cover image be included, with a linear=“yes” value added to its Spine entry, even though in the earlier Section 3.2.3 they unequivocally state that you are only to do this in reflowable files - and with a linear=“no” Spine value added - because the cover image “may appear twice” - which is, in fact, exactly what happens.

Furthermore, the “Cover” link in the Kindle menu leads to the jpeg image of the cover, not to the HTML page containing the cover image when one is included, so there is no good reason to include one. When your readers click on the Cover menu link, they will be presented with two consecutive cover images in a row, one JPEG, then one embedded in an HTML page, making them assume the page just isn’t turning. Therefore, there is simply no reason whatsoever to include an HTML cover, and every reason not to.

With the 2.8 update to Kindlegen, this cover issue has been somewhat addressed, and ironically by contravening Amazon’s own recommendation, since the conversion process now rejects HTML cover pages in most cases.

There is, of course, an exception to this rule: if the newly supported ePub3 NAV document is present, the HTML cover page is allowed, and in this case it functions correctly and is no longer doubled. However, there is still no advantage gained by included it, and the added hassle of creating a page to contain an image that doesn’t require it.

UPDATE 1-16-15: With Version 2014.3 of the Kindle Publishing Guidelines Amazon has reversed this long-standing error in their production policy. Section 4.3.7 has now been altered to state that "Any instances of HTML cover pages should be deleted to avoid a repetition of the cover image." Further, it goes on to say that only one visible JPEG cover should be included, and that it should be a high-resolution image of the same quality as subsequent pages. I have advocated for this for some time, and going forward will no longer test for this, as it has now become official policy. However, for the time being I will leave this section in for reference.

6. TOC Menu Link

This is the remnant of what was once a much more widespread issue, but now persists only in children's ebooks on the HD devices and the 2nd generation Fire, where the entire navigation menu is inexplicably missing. There is no “Table of Contents” or “Go To” link on the device menu of the newer Kindle devices when the “children” book-type value is entered, including no “Search” icon (incidentally, the search icon is present, but non-functional on the 1st generation Fire). The scrubber bar is fortunately still present, as well as the “Back” button, so navigation is not altogether impossible, but jumping to a specific pre-defined location is not possible.

There are also a few residual instances on other devices where the menu links are limited, as noted in the chart above, though nothing as significant as what was just discussed.

7. Bookmarks / 8. Live Text Functions

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 without having to buy a single one - are just some of the wonders that set ebooks apart.

And yet Amazon has somehow decided (intentionally or otherwise) that these features are not needed in fixed layouts. With either the "comic" or "children" book-type entered all live text functions are disabled. Only on the PC app are they available in all instances, and then so poorly executed that they're useless. The only way to add the live text features into a Kindle fixed layout ebook at present is to leave out the book-type property altogether; and even then they will still not work on the Paperwhite or iOS app, but everywhere else they will.

This might not seem so tragic to some (though to my mind it still is) since comics and children's books don't generally require notes and highlighting, as adult prose narratives and non-fiction often do. But two factors rule against this point of view, the first of which is that on general principle it should always be available for the reader, should they want it. That is a decision best left to the end user, not the retailer. It hurts no one to have the features present, but hinders those who want them if they're absent. The second factor is that the comic book-type is not used only for comics, strictly speaking, due to the higher image file size allowed with that book-type on the older, non-HD devices, and the fact that it's the only option that allows page-spreads (in most cases), which are often wanted in children's books as well. These are demonstrably erroneous decisions on the part of the Kindle OS developers, who have in essence sabotaged their own product and made it sub-par at best, for no discernible reason that I can fathom.

What this ultimately means in practical terms is that you can have either two-page spreads or live text, but not both, which I find frankly insulting. You could, of course, simply design your pages to the landscape aspect ratio and lock the orientation, thereby gaining both in technical terms. But this is a workaround at best, and a compromise that should not be necessary, and moreover, one that eliminates the ability for the reader to view single pages in portrait at the larger size this allows on the widescreen Kindles, which are not well suited to two-page spreads in any case for this reason. Proper two-page layouts require the 4:3 aspect ratio of the iPad and the newer Samsung Galaxy tablets. Curiously, eInk screens have unanimously adhered to the 4:3 ratio.

Bookmarks have been separated out here, since there are some odd discrepancies that do not correlate to the live text functions - primarily in “comics” on the Android app, where bookmarks are available, but only when Region Mag code is absent, and in children's ebooks on the Android app, which function only when Region Mag is present. Additionally, the Paperwhite supports bookmarks with all book-types, showing that this is not a “comic” or “children” issue specifically, but a glitch somewhere in the Kindle production system.

The lack of interactivity functions is not a fixed layout issue specifically, some odd quirk in the Kindle fixed layout code, since when you delete the book-type value altogether (or enter “none”) all this functionality is there (save on the Paperwhite and iOS app), with the fixed layout still intact. Moreover, it used to function with the “children” book-type as well, then for some inexplicable reason was actually removed. The “comic” book-type has not had these features from the very first.

A further issue, mentioned in the footnotes above, and which pertains to all interactive functions on the Kindle for PC app (i.e hyperlinks, live text, and magnification regions), is the incorrect placing of active tap areas. The layout engine for that app incorrectly renders the positioning of tap target areas, regardless of whether they are manually added in the code (as in MagZoom features) or are an innate part of the structure (i.e. text with an anchored link surrounding it, or simply tapping on a word to access the dictionary). The tap zone tends to be moved left and down from where it should be placed, and consequently hyperlinks are not linked, but instead their links are incorrectly aligned over other words. Moreover, when you tap and hold a word to bring up a dictionary, it defines a different word several lines away! My guess is this has something to do with the extra left/right borders added to the layout for the active page turn areas on the desktop, but in any case, there is nothing to be done for it but grit your teeth and know these features do not work correctly on the PC app at present.

9. Hyperlinks

Somewhat similar to the live text problem is the issue of interactive hyperlinks, both internal and external. Here this is once again tied to the “comic” book-type, which completely disables all text hyperlinks on the newest Kindle models when the Region Mag is absent. If Region Mag code is present, both internal and external hyperlinks work, but not otherwise. External hyperlinks are even colored blue, as if they're actually functional, but they’re completely inactive.

In all other cases, with the sole exception of the Paperwhite, hyperlinks work correctly even where live text is disabled. On the Paperwhite, all links are disabled in every instance.

10. Layout-Blank

This is an issue that was introduced with the inclusion of the “Page-Id” properties to the Spine entries. Essentially a page with this property is intended to be visible only in landscape orientation, but absent from the portrait view, ostensibly to produce a two-page spread where only one page of content exists (and therefore only necessary in landscape orientation). It has never worked correctly from the very start, and only does so now in a limited set of circumstances, even though it's still listed in the Kindle Publishing Guidelines as if it were a fully functioning entity. As you can see from the chart above, this is far from the truth.

In some cases the page is always visible, while in others it's never there (the latter of which is more true now than ever). Pages with the “layout-blank” value used to be accessible from a menu link in certain cases, even though they were otherwise invisible in either orientation, making it potentially a “hidden” page feature, but this is no longer possible (and since not intended, probably just as well). Unfortunately, the functionality of this feature in the vast majority of cases is not at all as stated or intended, rendering it all but useless for all intents and purposes.

Further, while the Kindle Publishing Guidelines states explicitly that "layout-blank" is the default “Page-Id” value (!), this is demonstrably (and logically) untrue. Were it so, no pages without some other layout value assigned to them would ever appear in portrait orientation! How this ever got approved for inclusion in the Guidelines as a working feature is beyond me. Clearly no one at Amazon has ever actually bothered to test this.

Back To Top

Join Me
On Google+

View My Vids
On YouTube

envelopeSubscribe To
My Newsletter