View Cart

Kindle Fixed Layout Tutorial, Part 6

Kindle-Specific Metadata

The first group of attributes in the metadata section are those that pertain specifically to Kindle fixed layout ebooks. You will find a complete list in under the Additional References listed in the index. The first of these attributes is the one that makes the layout fixed, and is found at line 10 of the Simple Template's OPF:

<meta name="fixed-layout"content="true/false"/>

This tells the Kindle reading system to display the content exactly as defined in the html and css files. This radically alters some basic functions of a Kindle reader, foremost of which is the disabling of the Settings menu (Aa), where Font size and style, margins, and background color options are contained. That means, of course, that none of these can be changed by the reader, so it's up to you to make the content legible. In many cases, that's where Region Magnification comes in. But good typography will go a long way to presenting your work in the best light.

The convention for a named metadata attribute (as opposed to a property, as seen in the EPUB3 section just beneath the Kindle section) is to give its name followed by a content value that defines a variable.

The only real option here for the content value, of course, is "true", since if you're entering "false" then you are not making a fixed layout ebook, and nothing else that follows in this tutorial will apply. Hence, this is a required attribute for Kindle fixed layout ebooks, and the required value is "true".

Note that the actual data in the Kindle section is given in quotes as a content value, rather than between angle brackets, as in the standard metadata section.

The ordering of metadata elements in the OPF, by the way, is entirely up to you, as long as they are all entered within the <metadata> </metadata> tags. I prefer to put the Kindle ones first, since they are unique to this format, while the rest belong to the standard ePub structure that is found in virtually every modern ebook file. But it is entirely up to you.

Be sure to close the entry with a forward slash before the final angle bracket. This tells the operating system that we’re done with this item.

Next up is the orientation function:

<meta name="orientation-lock" content="portrait/landscape/none"/>

This is the attribute that determines if the orientation is fixed as well as the content, or if the pages are allowed to reorient as the device is rotated to either a horizontal or vertical position. Options here are "portrait", "landscape", or "none", which is the one that allows auto-reorientation. Another way of selecting "none", of course, is just to leave the "orientation-lock" attribute out altogether.

A new features in KF8 called PageID allows for two-page spreads in landscape orientation (which will be discussed in detail shortly), but at present it is not universally supported across all Kindles, so that in many cases only a single page can be viewed in landscape rather of two. This will likely change in future updates, but it's something to take into consideration at the moment when planning your layout.

Additionally, the widescreen aspect ratio of the Kindle Fire line makes auto-rotation less ideal than the 4:3 ratio of the iPad, which retains a larger page size in landscape than the Fire. Only the Fire HD 8.9" has a display size large enough to make two-page spreads effective, but designing ebooks for a single model ignores too many potential readers to be a serious consideration. I am in hopes that Amazon will eventually transition to 4:3 ratio displays, but for now we have to work with what we've got. That said, it's probably best to plan for single page displays, whether portrait or landscape in dimension. Enter your chosen orientation as the content value here.

Note that the Kindle Publishing Guidelines list this attribute as being required for children's ebooks, but optional for comics. However, it does not state that any given value is required, and therefore, "none" is technically an acceptable option (even though this is the same as not adding the attribute at all). That said, the idea is clearly to provide as consistent and simple a reading experience as possible for children, without the pages skewing around and confusing them. For that reason a fixed orientation is in most instances the best choice for children's ebooks.

NOTE: The following attribute is no longer valid!!!

If there is RegionMag code present anywhere in the ebook then this value is set to “true” by Kindlegen - automatically - otherwise it is ignored, regardless of the value you have entered. The information is presented here in the event that this changes, and to provide an explanation of what it was originally intended for. But the metadata entry itself is currently irrelevant.

<meta name="RegionMagnification" content="true/false"/>

Region Magnification is a set of features in KF8 that allow sections of text, or segments of images, to be zoomed to a pre-determined size by double-tapping on an active “Target,” thus allowing portions of the page to be enlarged for greater visibility. At best this is a compromise for dealing with smaller display sizes, where content can become truly cramped, as, for example, on a 4” smartphone screen, where fixed layout text can be completely illegible.

And while it may seem inconceivable that anyone might attempt to read a comic book or graphic novel on such a device, believe me it will be done. The good news is that with Region Magnification it can, in fact, be a very pleasant, and even unique, reading experience. The relatively high resolution of the average 4” smartphone screen produces a vividly crisp and rich image, and with some forethought on your part - and some well designed Mag Regions - you can make it quite enjoyable for your readers.

In fact, as you can see by looking at the examples in the Advanced Template, there is much more you can do with Region Mag than just zooming bits of text or magnifying comic book panels. For example, you could create a completely different version of your ebook with alternate formatting for smaller screens.

Options for this attribute are “true” or “false”, but again, as mentioned, if Region Magnification code is present in any page the value will be set to “true” by Kindlegen, regardless of the metadata value that you enter here yourself.

That said, you should enter the “correct” value anyway, until such time as Amazon officially retire it from the Guidelines, in case its functionality changes at some point in the future. It is currently listed as an optional attribute, with the default value being “false”.

<meta name="original-resolution" content="widthxheight"/>

This is the only other attribute that is required in all Kindle fixed layout ebooks. The "original-resolution" value sets the default page dimensions (in pixels) for your ebook, using the format of "width x height" (with no spaces, such as "600x800"). This is not necessarily the size at which the page will be viewed, but the display resolution and aspect ratio for which the pages were designed. The Kindle will scale the page content up or down to fit the display on which it is actually being viewed, keeping the aspect ratio and content placement relative to the overall size.

Nor is the "original-resolution" necessarily the size of the images that you will include in a given page, since an image of any size can be made to display at whatever dimensions you choose, by defining that size in the relevant CSS. An example of this is the thumbnail cover image of this ebook tutorial that is found on the promo page of the Advanced Template (page 2, or the first page after the title page), where the image is displayed as a small thumbnail, but is actually 1200x1920 - larger than the "original-resolution" setting - so that it can be double-tapped and zoomed to fill the entire screen without "pixelating" (that is, going all fuzzy), even on the HD8.9" Kindle. Nearly every background image in the template is this size (with a few exceptions that will be explained in due time), so that readers using higher resolution devices won't be treated to a less than pristine viewing experience.

To facilitate accurate scaling, it is recommended that you use percentage values rather than pixels for all placement and sizing of elements on a page. So, for example, the cover thumbnail just mentioned is displayed at 38%, with a top margin of 18%, rather than specifying an exact size and placement in pixels. This way, regardless of how large the page is displayed, the image will always be 38% of the full page size, and 18% from the top. Had we used pixels, the image would appear to shrink in size and move closer to the top as the display dimensions (or resolution) grew larger: 18% of the 1280 pixel high Kindle HD7 is 230 pixels from the top, but 230 pixels is only 12% from the top of the 1920 pixel high HD8.9" Kindle.

I will discuss display resolution and aspect ratio in more detail in the section on creating images, and further when we start to place our content on the pages.

My recommendation at present is to design your pages at 800x1280 pixels (or 1280x800 for landscape pages), since the 7" Kindle is by far more widely used than the more expensive HD8.9.

NOTE: There is an updated and greatly expanded discussion of Aspect Ratio and Resolution in the published guidebook, to account for the latest changes to the Kindle reader line.

<meta name="book-type" content="comic/children/none"/>

A particularly unusual element with unique characteristics, "book-type" is an optional attribute with no clear function. The allowed values are "children" or "comic", but once again, since it is listed as being optional, "none" is a viable option (and in most cases the best one). You can enter "none" or simply leave it out altogether, with the same effect.

As presented in the Guidelines, the implication is that the “book-type” entity somehow effects the Region Magnification functions, with the “children” value being used for text zoom and the “comic” value for images, while a third “hybrid” method is possible for zooming text in comics as well. But this does not prove to be the case, as zoom functionality has nothing whatsoever to do with the book-type. In fact, both text and images can be zoomed with either book-type chosen, or none at all.

Unlike the previous metadata attributes, which each have a clearly defined function with logical value options, the "book-type" element has been a mystery from its inception. Even Amazon appears to be confused about its purpose, since the first versions of the Kindle Publishing Guidelines in which it appeared [Versions 2012.1-4] unequivocally stated that it "Provides additional reader functionality specific to the classification of the book" (italics mine), while never explaining anywhere just what this "additional functionality" might be. Version 2012.5 of the Guidelines, however, altered this so that this attribute now "removes reader functionality (e.g. share) which may not be relevant for certain books such as children's" (again, italics mine).

Ironically, the "share" feature - the one and only function mentioned in the Guidelines as being "removed" by the book-type attribute, is actually disabled in all Kindle fixed layout ebooks, regardless of the book-type. Moreover, several features are activated by entering either the "comic" or "children" value.

No other functionality is mentioned specifically as being altered by the "book-type" setting (with the one exception of image file size, which we'll get to in a moment), but I have been testing this since early March of 2012, and have determined not only which functions are effected, but also on which devices and apps, since there are now multiple iterations of the Kindle operating system in use.

In short, what I have discovered is that the "book-type" attribute actually alters at least nine different functions, including the disabling of all "live" text features (i.e. text search, dictionaries, highlights, and annotations), as well as bookmarks, hyperlinks, menu functions, while enabling several new features such as Virtual Panels and Page Spread on a handful of e-readers.

Making the issue even more perplexing is the fact that live text is available in fixed layout KF8 files so long as you don’t enter a book-type (or enter “none”) - both the “comic” and “children” book-types inexplicably disable all live text functions. But if you leave the book-type metadata line out of the OPF, the fixed layout KF8 will have all the live text features active, as well as region magnification and bookmarks.

The Fixed Layout Functionality Chart (Appendix A at the end of the published ebook manual, provided here for reference) provides a table containing a complete breakdown and analysis of feature support across Kindle apps and devices, and how they are effected by the "book-type" value, so be sure to study that for a thorough understanding of this attribute.

My recommendation overall is just to leave the "book-type" out, as it eliminates many features that are part of what make ebooks great. However, you may desire some of the features that this attribute activates, such as two page spreads and Virtual Panels on the Kindle Fire HD7, which are otherwise inactive. Unfortunately, at present you will have to sacrifice bookmarks, live text, active hyperlinks, and the Table of Contents menu link to get them.

Conversely, you may not need or want any of these features, depending on your particular project, so this is a choice you will have to make for yourself. For example, in an image-only graphic novel there is no need for live text functions, but the two-page spread might be essential.

Finally, just to complicate matters further, there is one more aspect of the book-type that must be considered, and that is image file size. From the very beginning Amazon has restricted the file size of images in Kindle ebooks to a ridiculously miniscule amount - initially to no larger than 127kb (which is still the limit for reflowable ebooks). This was recently increased to 256kb for all fixed layout ebooks, with the sole exception of those that have the “comic” book-type value, which are allowed to include images up to 800kb in size.

Why other fixed layout titles were not allotted this higher limit is a mystery, but presumably comics are allowed to include higher quality images to provide a better visual experience in graphic heavy ebooks intended for a more discerning adult readership. So if you happen to be publishing a comic or graphic novel, this is something you will have to weigh along with all the rest.

NOTE: With edition 2014.1 of the Kindle Publishing Guidelines the allowed image file size has been increased to 5 Mb per image, with an overall file size for upload to KDP capped at 650 Mb. While the Guidelines provide little further detail, what in fact now happens is that Amazon sends the full resolution images to the new HD Fire tablets, while standard resolution devices still receive the smaller, compressed images. So while you can now include larger images, you must still be cognizant of their quality when compressed to the older specs.


(Note that some of these will make sense only if you've read the commentary following the Kindle Fixed Layout Functionality Chart, or other relevant sections of this tutorial)

Reasons For Using A Book-Type Value:

  • New additional functionality, including Virtual Panels and 2-page spreads on some devices and apps (not yet widely supported, but likely will be)
  • Larger image file size allowed (800kb versus 256kb), and lower file compression upon upload to KDP if "comic" value is used
  • Black background on HD Kindles versus white on all other devices (cool, but not crucial)

Reasons Against Using A Book-Type Value:

  • Live text possible in fixed-layouts, including full search, hyperlinks, bookmarks, dictionaries, highlights and annotations
  • Background image pinch-and-zoom using double-tap outside of mag regions (functional only if the insertion method is used)
  • Unnecessary for Region Magnification features to function (as implied in Kindle Guidelines), including Panel View and Text Zoom.

These aspects are discussed in detail in the sections pertaining to text and images in the published guidebook.

Before moving on to the next section, there are a two additional metadata entries that must be addressed here as well, plus one special instance.

<meta name="primary-writing-mode">

This is a new feature recently added to allow for proper rendering of languages with any variation of directional reading, such as left-to-right page ordering in Arabic idioms and the vertical orientation of Asian languages. This setting changes the basic functionality of the page flow and navigation, as well as the sequence in which Virtual Panels and Magnification Regions progress when swiped. This will therefore be discussed in more detail in the sections pertaining to those features.

Options are variations of horizontal/vertical plus either lr or rl. That is:


This is an optional attribute, with the default value being "horizontal-lr".

<meta name="zero-gutter">
<meta name="zero-margin">

These attributes are discussed nowhere in any of Amazon's documentation, and none of my testing can discern any difference in the true/false value setting. I have removed every reference to margin and gutter settings in the CSS of a fixed layout test file, and varied these two metadata values in combination with every other Kindle-functionality attribute to no effect. There simply is no margin or gutter in a fixed layout file unless you add one in the layout itself.

Both margins and gutter for each page in a fixed layout Kindle ebook are set in the relevant CSS, and these two metadata values do not alter them in any way. Likewise, the default page margins found in Kindle reflowable ebooks are eliminated when the value of the "fixed-layout" attribute is set to "true", and it is accordingly no longer reflowable.

I only include these metadata entries here (and in the templates) for the sake of being thorough, but you can leave them out or in as you see fit.

And although it seems to make no difference, I should mention that these are only found in Amazon's fixed layout comic sample, and not in the children's ebook sample. But again, there is no explanation given anywhere for their inclusion. Therefore, I can see no reason to do so.

<meta name="cover" content="whatever">

The final element in the Kindle section of the metadata is the entry for your cover image. This is a required attribute,* and it must be given exactly as specified above, with the single exception that the content value can be (as suggested) whatever you would like to call it. The name value, however, must be "cover" in order for bookshelf thumbnails and the cover menu link to work. The content value will be mentioned again later, when it is referenced in the Manifest.

There is one further metadata element listed in the Kindle Metadata Attribute Chart from the Kindle Publishing Guidelines, which is the "page-id" attribute. However, this is not actually handled in the Metadata section, but rather in the Spine portion of the OPF file, so we will deal with it when we get there.

* NOTE: This element is no longer required if, and only if, the properties=“cover-image” attribute is included in the cover image item entry in the manifest. See the Manifest section below for more details regarding this.

For a complete discussion of the new ePub3 metadata entries, as well as the Nav "landmarks" and "toc" elements, see the complete ebook tutorial!


Join Me
On Google+

View My Vids
On YouTube

envelopeSubscribe To
My Newsletter