Read A Sample - Fantasy Castle Books

Get the Companion Templates
- FREE!
Both the “Simple Edition” and “Advanced Edition” Templates can be
downloaded from:
Scot’s Blog
Use the code KF8FLEBOOK to get them free!
www.fantasycastlebooks.com
A Fantasy Castle Publication
ISBN: 978-0-9821538-5-7
Revision History:
Version 1.0: May 2013
Version 2.0 May 2014
Text & Illustrations
©2012-2013 R. Scot Johns
All Rights Reserved
3D models Bong & Bonga
©2009 by Frank van Rueschen (Nursoda)
Bingo texture for Bong
©2009 by Lisbeth Hviid Jakobsen (TrekkieGrrrl)
LucyLoo texture for Bonga
©2009 by Susan McKivergan (Sveva)
Amazon, Kindle, Kindle Fire, and Paperwhite are registered trademarks of
Amazon.com, Inc. All other trademarks are the property of their respective owners.
This book is not written, published, or endorsed by Amazon.
This eBook is copyright material and may not be reproduced, distributed, sold,
leased, licensed, or used in any way, in whole or in part, except where Fair Use
allows, without the prior written permission of its author. Any unauthorized use may
be considered a direct infringement of the author’s rights, and is liable to punishment
by law.
Table of Contents
Introduction .................................................................................... 1
What is Fixed Layout?............................................................... 1
The KF8 Format ........................................................................ 3
Why Kindle?.............................................................................. 5
Working Methodology ................................................................... 7
The Templates .............................................................................. 11
Tools............................................................................................. 16
1. Content Editing.................................................................... 16
2. Conversion Tools................................................................. 19
3. Third-Party Utilities............................................................. 23
4. Documentation..................................................................... 25
PART I: The File Structure .......................................................... 27
Opening the File ...................................................................... 28
Inside the Template.................................................................. 29
The OPF File ........................................................................ 31
1. Metadata ....................................................................... 33
2. Manifest........................................................................ 64
3. Spine............................................................................. 67
4. Guide ............................................................................ 72
The Navigation Files ............................................................ 78
1. The NCX File ............................................................... 79
2. The NAV File ............................................................... 83
PART II: The Content .................................................................. 87
IMAGES.................................................................................. 89
Resolution & Aspect Ratio................................................... 90
Image Format & File Size .................................................... 95
PAGES .................................................................................... 99
HTML & CSS for Fixed-Layouts......................................... 99
THE BASIC TEMPLATE ..................................................... 103
1. <div id> Insertion Method.............................................. 106
2. <img src> Insertion Method ........................................... 111
3. Self-Contained CSS Pages ............................................. 114
4. Active Links ................................................................... 116
5. Multiple-Image Pages..................................................... 118
THE ADVANCED TEMPLATE .......................................... 126
FONTS ............................................................................... 128
Live Text ........................................................................ 128
Embedding Fonts............................................................ 130
Text Shadows ................................................................. 133
PAGE LAYOUTS.............................................................. 137
1. Live Text Layers......................................................... 138
2. Relative Positioning.................................................... 150
3. Active Table Of Contents ........................................... 155
4. Stacking Text & Image Layers ................................... 164
5. Positioning Text Boxes............................................... 173
REGION MAGNIFICATION............................................ 176
1. MagTargets Using “SourceId” ................................... 180
2. Alternate Content & Placement .................................. 194
3. Text Positioning & Alignment.................................... 201
4. MagTargets Using “TargetId” .................................... 207
5. Lightbox Fills Using TargetParent ............................. 216
6. Panel View Using TargetParent.................................. 221
7. Full-Page magTarget Example ................................... 241
PART III: Conversion & Testing ............................................... 244
Compiling The File................................................................ 245
Converting The File............................................................... 247
Kindle Direct Publishing .................................................... 247
Kindle Previewer................................................................ 249
Kindlegen ........................................................................... 251
Mobi7 vs. KF8................................................................ 257
Kindle Unpack................................................................ 259
Testing The File..................................................................... 262
APPENDIX A ............................................................................ 266
Kindle Fixed Layout Functionality........................................ 266
APPENDIX B............................................................................. 280
Kindle Metadata Attributes.................................................... 280
APPENDIX C............................................................................. 282
Standard Metadata Attributes ................................................ 282
APPENDIX D ............................................................................ 284
Device Display Resolution .................................................... 284
Introduction
What is Fixed Layout?
Comics and graphic novels, as well as many illustrated children’s books and
non-fiction works, contain complex layouts and graphic elements, such as
full page images and precisely positioned text, that require special formatting
not available in standard “reflowable” formats (such as the one you are
reading now). Reflowable ebooks allow users to resize text and margins, and
even change the font style or background color. Conversely, “fixed-layout”
content is... well... fixed, displayed exactly as the ebook creator made it.
And while reflowable features are among the chief aspects that make ebooks
truly unique, it is incompatible with highly formatted layouts such as graphic
novels and magazines. Graphic design is an art form, with a long and
illustrious history of development that has refined the arts of composition,
typography and illustration over the course of centuries. Fixed layouts allow
that art to be preserved in digital format, while still retaining many of the
interactive elements that are not possible in electronic documents such as
PDFs, or those that contain just images (although they can do that, too).
2
Fixed layout formatting supports “full-bleed” artwork (i.e. edge-to-edge, with
no surrounding margins), as well as the layering of multiple elements on top
of one another, allowing complete control over the page contents. All this is
done using a fairly limited set of HTML and CSS for styling and placement,
as well as a bit of extra code for Kindle-specific features such as Panel View
and Region Magnification (the Kindle format’s text and image zoom
functions).
You don’t need to know very much code to make an ebook work, but of
course, the more you do know, the more complex your design can be. In this
tutorial you will learn all you need to know to create layouts as simple or
complex as you like.
This guidebook explains how to create fixed layout ebooks for the Kindle
platform only. It does not delve into reflowable formatting, nor creating fixed
layout files for other platforms such as Nook or iBooks, which have their
own proprietary formats. And while they share many common features,
Kindle ebooks are unique in the way they’re made, and in this book you’ll
learn how that is done, so that you can to do it for yourself.
3
The KF8 Format
With the introduction of the full-color Kindle Fire reader in November of
2011, Amazon also released a new ebook format known as Kindle Format 8,
or “KF8” for short, as the successor of the preceding Mobi7 format. KF8
included many new features that Mobi7 did not support, including fixedlayout capability for creating image-heavy ebooks with text overlays, as well
as text and image zoom, much of it based on proprietary code that only
Kindle apps and devices can read.
Initially only the Kindle Fire could read KF8, but within a year of its release
the format had been rolled out to nearly all of the Kindle line of apps and
devices, with regular updates to include new features. All Kindle devices
from the third generation forward now support this format, including Kindle
Keyboard and Touch (but not Kindle 1 or 2), as well as all updated Kindle
apps for PC, Mac and Android.
However, not all Kindle e-readers yet support all of the functions of KF8, so
you should be aware of what is possible at present when preparing to begin a
new project. Appendix A contains a chart detailing device and app support
for the major features of the Kindle fixed layout format that are still not fully
supported, or only function under certain circumstances. These will be
discussed at length throughout this manual, and in further detail in the notes
for Appendix A.
4
Ironically, Mobi7 is the only Kindle format that currently supports audio and
video, meaning that you cannot produce fixed layout Kindle ebooks with
these features at the present time. Therefore, this tutorial does not cover those
functions, although it will be updated to include them at such time as
Amazon decides to make them available in KF8. For those interested, the
Kindle Publishing Guidelines contains details on the creation of reflowable
ebooks with embedded audio and video.
The ebook you’re now reading uses reflowable formatting, so that all Kindle
apps and devices can read it. It has images placed in between the blocks of
text (not layered behind or beneath the text), so that the images flow along
with the text in any display and at any font size. You can also make
reflowable ebooks containing only images, but there will be a white margin
around the outside that will reduce the size of the useable image area. To
create ebooks with “full-bleed” images that stretch edge-to-edge (i.e. without
the outer margin) you must use fixed layout formatting.
You will have to decide for yourself if fixed layout or reflowable is the right
choice for your project. In general, if it can be formatted as reflowable
without losing important aspects of the design, then it probably should be,
since fixed layout removes some features ebook readers like, such as text
resizing, and it can be read on any device. It can also be more complicated
and time-consuming to produce fixed layouts, depending on the project. But
for image-intensive ebooks with complex layouts such as graphic novels and
many children’s books, fixed layout is often the only choice.
Kindle for iOS
Kindle for iOS is a special case at present, since KF8 files cannot be
transferred manually to the iOS app with all their fixed layout features intact.
Until recently, in fact, all fixed layouts were converted to reflowable files
during transfer to iOS devices, since only the older Mobi7 portion of the file
was actually transferred.
However, with the release in June 2013 of Kindle Previewer 2.9, KF8
files could for the first time be successfully transferred to iOS devices via
iTunes using the new iOS compatible .azk file that Previewer produces when
using the "Kindle for iOS" setting. Unfortunately, some layout elements are
still not rendered correctly, and magnification features do not function at all.
Thus, fixed layout ebooks cannot be tested accurately on the iOS platform
during production. Be sure to watch for updates, though, as Amazon are
always working to improve the process, of which these publishing tools are a
vital part.
5
That said, the Kindle for iOS app does, in fact, support KF8 fixed layouts
with full-page images and region magnification functions, and these will be
available to users who download the ebook file via the Kindle for iOS app
once it is available to purchase. If you produce a title that is fully functional
on a Kindle device or the Android app, you should feel fairly confident that it
will also work correctly on an iOS device.
You should, of course, always test the file by downloading it to an iPad or
iPhone from Amazon once it is available for sale. If there are errors you can
fix them and upload a new file. This is the only viable solution at present.
Why Kindle?
Why choose Kindle for your fixed layout ebook? For one thing, Amazon
sells more ebooks than anyone, with an overwhelming majority of the ebook
market since the Kindle first arrived in November 2007. It is estimated that
Kindle ebooks make up roughly 55-65% of all sales currently, with no other
competitor able to claim even half of that. So if you’re going to target one
particular platform as the place to start, then the Kindle is it.
Moreover, few businesses have done more to promote the cause of selfpublishing than Amazon, pioneering the independent ebook revolution with
their KDP program, which is continually developing and improving. In
addition, they are constantly expanding into new global markets and
developing new technology to improve ebook readability and distribution.
Amazon almost single-handedly revolutionized the ebook industry with the
creation of a complete content ecosystem, from creation to delivery to final
device display, with such innovations as instant purchase and download right
on the device, ebook lending and gifting, and automatic syncing between all
your Kindle apps and devices. They may not have invented the ebook, but
they certainly revitalized an industry that had lain dormant until then.
6
In many ways the Kindle format is still in its infancy, with new features
being added (and Kindle e-readers being upgraded to support them) all the
time. Some of these are half-baked, and some are only functional in certain
instances, on a particular device or app. But the format is progressing at a
steady pace, becoming better all the time. We are as yet in the very early
years of the digital transformation, on the edge of a frontier with no horizon
anywhere in sight.
Since the release of the first Kindle in 2007 digital publishing has exploded,
seeing triple-digit sales increases every year from 2008-2012, with a
“modest” growth of just 134% in 2012, according to Publisher’s Weekly.
Most of that has been reflowable content, while image-heavy content has
lagged behind due to limitations in technology. But with the introduction of
multimedia tablets with high resolution, full color displays that has changed,
and the illustrated ebook market is set to explode in the coming years. Now
you’re limited only by your imagination - and how much code you know. So
let’s get to work!
7
Working Methodology
This tutorial is written as a step-by-step guidebook that takes you through the
contents of two working ebook templates - both of which you can download
for free - beginning with a simple, image-only template, and progressing in
stages through more advanced layouts with multiple layers and various
magnification methods. Every element and line of code is looked at, more or
less in the order one would normally create them, beginning with the
necessary support files for ebook functionality, and concluding with artistic
page layouts and tricks with interactive elements.
Because of this, this manual is intended to be read from start to finish as you
work your way through one or both of the example files. However,
depending on your skill level and prior knowledge, you can jump in at any
point and look at just the sections that you want to learn. To this end there is
some built-in redundancy within the separate sections to make them more or
less self-contained (although I have tried to minimize the replication as much
as possible). Consequently, some points will be made more than once. But
then, repetition is most often the best method of learning.
Each required file and content page is given its own section, where it is
dissected and discussed, being treated as a separate lesson, although the latter
pages presume some knowledge of what was learned in those that came
before. Where a previous section is relied on for a later example this is
pointed out so that those who dive in at a given point can go back and
reference the earlier information.
8
The intention of this tutorial is to teach you how a Kindle fixed layout ebook
works, at its root level, so that you can use that knowledge to produce
professional quality illustrated ebooks of whatever type you choose, with the
maximum number of options at your disposal.
To that end, the methods described in this manual utilize “hand coding” from
start to finish, rather than relying on software interfaces that contain their
own quirks and features and can often produce unreliable results, or garbled
code that only a machine can read. Only by building ebooks from the ground
up can you know exactly what is in a file, and understand what to do if
something goes wrong (as it inevitably will).
But even if you ultimately use a third-party program or ebook conversion
service to produce your file, you will be better positioned to correct any
errors that crop up, or adjust and improve its appearance and functionality
(such as when new Kindle updates are released, or reader feedback is
received) if you know what makes a given feature work in the first place (or
not work, as the case may be).
The fundamental purpose of this guide is to walk you through the contents of
a working Kindle fixed layout ebook file, and explain why each part is there
and what it does. What you do after that is up to you.
Comics vs. Children’s eBooks
There are ostensibly two fundamental types of fixed layout ebooks that can
be made in Kindle Format 8. Amazon divides these into the “children” and
“comic” categories, even though this is a rather broad and arbitrary labeling
scheme, since any genre, reading level, or subject category can be produced
in either type. Yet there are significant differences between the two, as you
will soon discover.
Moreover, if you read through the Kindle Publishing Guidelines you will find
some confusing and often contradictory information regarding these two
classifications.
According to the Guidelines, the primary difference is that “comics” consist
entirely of full-page images, while “children’s” ebooks include text laid over
the top of background images. Both can include interactive Region
Magnification features. In the case of comics, the “Panel View” function
enlarges a pre-defined area of the full-page image when double-tapped, while
the children’s format includes the ability to magnify text boxes. But, in fact,
this isn’t entirely accurate, since comics can include text overlays and
children’s books might consist only of images.
9
Still, each has these inherent features for a reason, and each will be discussed
and analyzed at the appropriate time. For practical purposes this division
suits us here, since there are presumably two essential groups of people
reading this manual:
1. Those who want to make simple, image-only ebooks (i.e. comics and
graphic novels, with their text included in the images)
2. Those who want to create more complex layouts than reflowable format
allows (i.e. children’s picture books or other illustrated content with
interactive text or image layers)
With this in mind, we will begin by covering all the necessary steps in
producing image-only ebooks in Kindle format, from start to finish, and then
progress to add in text layers and region zoom features. In that way everyone
can start at the beginning and jump ship when they’ve learned what they need
to know. Along the way a number of tips and tricks will be provided to show
just a sample of what else might be done with Kindle code, apart from what it
was designed to do.
The Contents
The tutorial is divided into two primary parts. Part I details the functional
components of a Kindle fixed layout ebook - that is, the parts that make the
ebook itself work - while Part II covers all aspects of the content that the
ebook can contain. There is necessarily some overlap here, as each affects the
other to some degree. But, in essence, if you already know more or less how
a Kindle ebook works, or you just want to use one of the templates as the
container for your own content, then you can jump to Part II and refer back to
Part I when necessary.
As for our plan of attack, a glance at the Table of Contents will provide a
thorough outline, but here are the essential steps:
PART I:
* A look at the necessary Tools, including the free Templates, which will
be our project guide throughout the tutorial.
* An overview of the File Structure of a Kindle fixed layout ebook,
followed by a detailed look at each of its component parts:
* The “contents” file: the OPF, including its Metadata, Manifest, Spine,
and Guide items;
10
* The “navigation” files: the NCX, including its Metadata, NavMap, and
PageID features, plus the newly added EPUB3 NAV file, including TOC
and Landmarks.
PART II:
* Creating images for Kindle fixed layouts, including the cover and internal
content.
* HTML page layout, including CSS styling, for image-only ebooks.
* Live text layers, including hyperlinks and text positioning.
* Embedding fonts for customized typography, including text shadows.
* Region Magnification code for both text and images, as well as creating
Lightboxes.
* HTML & CSS for Panel View, including how to position content
accurately.
* Tips & Tricks with zoom functions, such as switching text and images.
* Converting and testing your file using Kindlegen and Previewer.
Each of these are subdivided into smaller parts, detailing what each file or
section of code does and what your options are for each. Some sections are
short and to the point, others somewhat long and complex, but all as detailed
as they need to be in order to explain them thoroughly. So with that, let’s get
started!
11
The Templates
Two fixed layout files are available to download for your use as templates or
demonstration samples, both of which are referenced extensively throughout
this book. While I have tried to include all relevant code for each feature
here, along with key screen captures to illustrate each point, having the actual
file to look at will prove useful in most cases, particularly if you want to see
how a given feature works or how a page looks when rendered on an actual
device.
You can download the companion files from the Templates tab on my blog:
Kindle Fixed Layout Templates
Use the code KF8FLEBOOK to get them free.
The first is a simple, image-only ebook, containing 11 pages illustrating
several ways to embed full page images in a fixed layout file. This would be
a good choice for comics and graphic novels where all text is contained
within the images and Panel View is not required (a note on “Virtual Panels”
is included at the end of the Simple Template section in this book).
The second is a more advanced and complex edition, containing all of the
image-only options of the simple version, plus live text overlays, interactive
image layers, and region magnification for both text and images. All features
currently available in KF8 are demonstrated in this template, along with
numerous unique examples of their use.
Both the templates and this book will be updated as Amazon incorporates
additional support for fixed layout features in KF8. Be sure to subscribe to
Scot’s Blog, The Adventures of an Independent Author, to be informed of
future changes, as well as ongoing discussions of ebook formatting matters.
One of the key benefits of ebooks is the ability to quickly update and release
new editions as needed, and to do so free of charge! For print edition readers
please be sure to stay tuned to the blog for details on all future updates.
12
The templates are provided both in Kindle format (.mobi) so that you can
view them as ebooks on your Kindle device or app, as well as their source
format (.epub), which can be opened and extracted so that you can look at the
internal files from which they are constructed, and use them as the basis for
your own.
Kindle files cannot be built or edited directly, but must be converted from a
“source” file, which is constructed as an epub document, modified to include
the Kindle-specific code. The epub file is just a zip archive containing the
contents of the ebook, along with a few support files that make it work. The
.epub archive, therefore, will form the basis of the file you will build before
converting it to the final compiled Kindle format.
It should be mentioned here that, while Amazon accepts Word docs and
HTML files into its Kindle Digital Publishing (KDP) ingestion system, ePub
is the only source that supports fixed layout content, and thus, the only one
that concerns us here.
The .epub template files will allow you to view the source code referenced in
this book, and replace the template’s contents with your own. This tutorial
provides step-by-step instructions on how to do just that.
How to Use the Templates
Both templates are completely functional ebooks, containing all the
necessary code to make them work. Each one contains a number of different
pages, each containing a particular example, or set of examples, of page
content and functionality, from simple image-only pages, to highly complex
layouts with multiple zoom regions and interactive areas. Each example
13
demonstrates what can or must be done to achieve a given result, and how to
do it.
Whatever the end goal for your project, it is always best to start out simple,
and progress to more complex content. Even if your ebook will have active
text overlays and region magnification throughout, start by making a simple,
one-page, image-only file that will open correctly in a Kindle reader. Once
you have the basic ebook functionality worked out, you can then
progressively add in features and more pages, one at a time, testing each one
as you go.
The easiest way to do this - and the primary reason why I have provided the
example files as templates - is to choose one of the basic page types in the
template of your choice, and replace its contents with your own. You can
leave all the other pages in until you’re ready to create your next page, or
delete them from the epub archive (making a copy of it first!) so that it
contains just the one page that you want to start with. If you do this, be sure
to delete all of the entries from the OPF manifest and spine sections except
for those that pertain to the page you’re retaining (you’ll learn about the OPF
in an upcoming section), otherwise you’ll get errors during conversion.
Once this is done you can simply exchange the current content of that page
for your own, deleting the original background image first and replacing it
with yours. Be sure to change the internal links in the HTML page so that
they reference your image (or just use the same name as the replaced file for
now), and alter the page size values to your chosen resolution, both in the
OPF and CSS. You don’t need to worry about deleting any CSS entries yet,
since those that are not used are simply ignored. Later on you can go through
and delete any that are unnecessary if you like, and of course, alter the styling
to suit your own work. You’ll learn how to do all this as we progress, so if it
makes no sense to you now, it will soon enough.
Always make a copy of your latest working version before progressing to the
next step. Number each one sequentially with a version number, both in the
file name as well as in the title of the book in the manifest. The reason for
this latter will be seen when we reach the section on conversion and testing.
After the file has been converted and tested to be sure that it is working
correctly with your image inserted, you can move on to the next page, or start
to add in text layers and any other overlays and code that might apply to this
page, being sure to add in only one element at a time and test it thoroughly
before moving to the next, as per the instructions given in this book for that
page type or feature. Once you become confident in your ability to make a
Kindle ebook that functions properly you can start to take on larger or more
complex portions at a time.
14
Believe me, there is nothing more frustrating or confusing as to hand code an
entire book only to find out after many hours of labor that it doesn’t work.
Taking it one step at a time assures that when something goes wrong (and it
will), you’ll only have to backtrack one step in order to determine the source
of the error, or return to an earlier working version without losing too much
time. If you build the whole book first before converting it you’ll have a
thousand lines of code in which the problem could be lurking, and it will take
ten times as long to find the problem, if you can find it at all. So save
yourself the headache and take it one step at a time.
Creating Your File Structure
There are two methods you can use to build your ebook using the templates,
either of which work equally well. The one you choose will depend on what
is easiest or most comfortable for you.
The first is to work directly within the zipped epub archive itself, deleting,
adding, and editing content using the tools discussed in the next section. This
method allows you to build a finished epub file from the inside out that is
complete and ready for upload to KDP without further processing. In
addition, during conversion using Kindlegen you simply reference the
location of the epub file, and Kindlegen converts it to a mobi file for testing
or distribution.
A minor drawback to this is that you need to open the archive in a file
compression program first in order to access the files contained inside, and
compressed files can sometimes be a little finicky to work with, depending
on your system and the program that you use. One primary benefit to using
this method, however, is that it is far easier to save multiple versions of an
ebook that is compiled (which I highly recommend), since you can simply
copy it and add a version number or date/time string to the file name before
making further changes to the duplicate.
The alternate method is to extract all of the contents from the template onto
your hard drive and work with the extracted file hierarchy there (or build it
from scratch). This lets you work directly with the uncompressed files during
editing, which is sometimes easier, since you can access them faster, and
drag and drop and replace/rename files easier. In addition, you can edit more
than one file at a time this way, which you cannot do when the files are inside
an archive. Moreover, Kindlegen will accept an OPF file as its input source
and compile the disparate files into the mobi output during conversion for
you, allowing you to skip the zip compression process altogether. The file
that it outputs, however, will have the same name as the OPF itself (such as
content.mobi, for example), so you will need to rename it each time, or risk
overwriting earlier versions of your work.
15
If, however, you want to create an epub from your folder hierarchy, you will
have the extra step of adding all the files to a zip archive first (which itself
can be tricky), and then changing its .zip extension to .epub before you can
do anything with the file. You might do this, for example, if you want to
upload an epub to KDP rather than a pre-converted mobi file, which will
have a larger file size that may exceed the 50Mb limit, due to its inclusion of
both the source file and the converted mobi7 and KF8 versions of the ebook
(this issue will be discussed further in the section on Conversion & Testing).
You may want to play around with both methods before deciding how you
will proceed, and you can always switch from one to the other by adding or
extracting the files to or from the archive. Just be sure to keep your files
clearly organized and your versions numbered logically so that you will
know exactly where you are in the process. Otherwise you may get confused
as to which files belong where, and which ones you messed with last, which
can very quickly become an enormous mess.
16
Tools
In addition to the Templates, a number of further resources will either be
required, or come in handy as you set to work creating your masterpiece.
1. Content Editing
I. Text Editor
Even if your ebook consists entirely of images, you will still need a good text
editor capable of creating clean, plain text files (i.e. not Rich Text Format,
but plain text) for inserting formatting data into a handful of required support
files. Preferably it should have numbered lines, as this will aid in editing
more lengthy files. The quickness with which the program opens can also be
a crucial factor, as you will be opening and closing it quite often.
I prefer Notepad++ on the PC, while TextWrangler for the Mac is a highly
popular free text editor. If you use the default PC or Mac text editor be sure
to turn off Rich Text and save your files as plain text, otherwise the code will
get garbled (for example, when curly quotes are used in place of straight
quotes). A good web building program such as Dreamweaver is almost
overkill for building ebooks, but will certainly do the job. One benefit of a
program such as this is the ability to look at HTML and CSS code side by
side. However, it will take longer to open and close the program.
Bear in mind, moreover, that third-party “What You See Is What You Get”
(WYSIWYG) interfaces do not always render ebook layouts correctly, since
they rely upon a different operating system than the Kindle readers will, and
do not inherently understand the proprietary portions of the Kindle code,
such as region magnification. You can use them as a starting point, but
17
always do your final testing in the Kindle Previewer, or (preferably) in an
actual Kindle device or app when possible.
A Note on InDesign: Adobe’s premiere layout software will export to ePub
format, but it also inserts its own quirks and bits of extraneous code into the
files that makes it more complex than necessary to edit, requiring a lot of
“clean-up” that is often far more work than creating a file from scratch. This
tutorial will not attempt to explain what you’ll need to repair, add, or remove
from your ePub file in such cases, but only what you need to put into it in the
first place. Once you’ve learned that, you’ll be more readily able to clean up
an InDesign exported ePub file, should you so choose.
But unless you know just what (and only what) needs to be in there, you'll be
at the mercy of the program and its designers. And that applies not just to
InDesign, but all ebook creation software, including Amazon's own Kindle
Comic Creator.
Additionally, Amazon offers an InDesign plug-in for export directly to .mobi
format, but this does not yet fully support fixed-layout features such as region
magnification, and introduces plenty of its own errors as well along the way.
Consequently, I do not cover InDesign exports of any sort in this tutorial.
However, the files produced can be edited using the instructions contained
here, once you know what you’re looking for.
II. Image Editor
Presumably, if you are interested in creating fixed layout ebooks you already
have some image content that you want to use. Therefore, you are likely
already well versed in the use of graphics editing software. You might,
however, only have a handful of photos or some raw art, or even some comic
book page scans that you want to make an ebook of, and don’t know what to
do with them.
Images in Kindle ebooks need be correctly formatted both for pixel
resolution as well as file size. Thus, you will need a professional quality
image editor like Photoshop or Gimp that can resize images and accurately
compress them into JPEGs. In Photoshop, using the “Save for Web” option
gives you greater control over the final file size, with several options for
retaining the highest quality at the optimal compression level. Image size will
be discussed in further detail later in the book.
III. File Compressor / De-Compressor
As already mentioned, an epub file is really just a zip archive with its
extension changed. You can manually change the .epub extension back to
.zip in order to extract the files inside or add new ones, using any standard
18
zip extraction/compiler program.
Be sure to change your file browser’s settings to show extensions so that you
can edit them. On Windows systems this is accessed either from the Tools >
Folder Options section of Windows Explorer, or via Start > Control Panel >
Appearances and Personalization > Folder Options, where on the View tab in
the Advanced Settings section you will want to uncheck the box to “Hide
extensions for known file types.” For Mac users, this is found via the Finder
Preferences section, under the Advanced tab, where there is a checkbox to
“Show all file extensions.”
Some programs, such as 7-Zip for Windows and iZip for Mac (both free),
allow you to modify the contents of an epub file from within the archive
itself without changing the extension, or even extracting the files, which can
save you a great deal of time.
To do this, set your preferred text editor (i.e. Notepad++) as the default in the
extractor’s preferences section so that you can simply right-click on a file
from within the epub archive and select “Edit” to open and modify the file
without extracting it. In 7-Zip this is done in Tools > Options > Editor. You
can also drag and drop new files into the archive, or delete ones that are
already in there, all without extracting anything.
The one thing you cannot do is duplicate a file from within the archive;
instead you simply drag the file you want to copy to your desktop, thus
making a new version of it, and then change its name (and edit it right there if
you so choose), before dragging it back into the archive as a new file. This is
one way you can use a template to create new pages. Just be sure to list the
new page in the manifest (which we’ll get to in a bit).
An alternative is to build the ebook’s folder structure on your hard drive and
either convert it directly to mobi format or add it to a zip archive to create
your source epub once the files have been edited. But again, these options
will be discussed in detail in the section on Conversion and Testing.
19
2. Conversion Tools
I. Kindlegen
As mentioned, Amazon provides a free conversion tool called Kindlegen that
will produce a final Kindle compliant mobi file that can be uploaded to KDP
or distributed to Kindle customers as you see fit. This is the workhorse of
your Kindle production pipeline, and will provide you with both fast and
accurate conversions, as well as a log detailing any warnings or errors in the
output file that need to be addressed.
Kindlegen is a command line tool that is easy to use, accepts epub input (as
well as X/HTML and OPF), and supports all the features of KF8 fixed layout
format. Although it may appear complex at first glance, don’t let this put you
off, as it is really very simple, and its use will be fully explained in this
tutorial. It is available for Windows and Mac, as well as Linux.
A Note on Calibre: Many ebook creators rely heavily on a readily available
(and often updated) free software package called Calibre, created by Kovid
Goyal. While Calibre is a fabulous program that I highly recommend, both
for reflowable ebook conversion and organizing your digital library, it does
not support fixed layout formats, due to their complexity and the proprietary
nature of the code, which will not work in other formats (and thus, cannot be
converted correctly to them). Do not attempt to use it to produce fixed layout
ebooks in Kindle format. But by all means, use it for everything else.
II. Kindle Previewer
Kindle Previewer is another free tool offered by Amazon that is intended to
be used (as the name suggests) for previewing your Kindle file before
20
uploading it to KDP, allowing you to view your ebook as it will look on
different Kindle readers. Previewer actually functions as a graphic user
interface with Kindlegen, automatically converting epub inputs into Kindle
format for previewing. Consequently, you may prefer to use it for this
purpose rather that accessing Kindlegen directly. But either way your files
will be converted by Kindlegen, which you must have installed (the
Previewer setup will do this for you).
However, there are some drawbacks. Previewer is supposed to function as an
emulator, allowing those who do not own a particular Kindle app or model to
see how their ebook will look on any given display. Since few authors can
afford to purchase every device available, this can be quite useful.
Unfortunately, Previewer has been plagued with bugs and is notorious for not
displaying content accurately. It will, for example, show two-page spreads
for devices that do not support them, and region magnification does not
always function as it should, even when coded correctly. Conversely, page
layouts will sometimes render correctly in Previewer, but not on the actual
device. Needless to say, it is unreliable at best.
Ultimately, it’s better than not having any idea at all, but I highly recommend
the real thing whenever possible. If you intend to produce a professional
quality Kindle ebook for sale to the public, it is incumbent upon you to
acquire at least one current Kindle device on which to test your product for
quality assurance purposes. You will earn your investment back in customer
satisfaction soon enough, which is priceless.
One further drawback to Kindle Previewer is that you cannot use it just to do
a conversion, since it automatically opens the preview window to your
default display mode once the conversion is complete. This takes a little
while, even on the fastest machines, and you cannot proceed (without closing
the program) until the preview has been rendered, which adds a series of long
delays into the production process.
On the positive side, the converted file will include a date and time stamp
appended to the file name, which makes keeping track of successive
iterations considerably simpler. In addition, as previously mentioned,
Previewer is the only tool with which you can create an iOS compliant
version of your Kindle file (which will have an .azk extension rather than the
standard .mobi).
III. Kindle Comic Creator
Although “KCC” (or KC2 as it is often called) is not technically a conversion
utility, it does perform that function via its interface with both Previewer and
21
Kindlegen. Kindle Comic Creator is yet another WYSIWYG graphic user
interface, released in April 2013, that ostensibly allows you to produce KF8
fixed layout comics using basic drag-and-drop functionality. I do not,
however, recommend its use for anything but the very simplest of projects, as
it has a great number of drawbacks that far outweigh its benefits.
Firstly, you can only create ebooks with the “comic” book-type: there is not
even an option to change this to the "children" book-type, or to leave the
book-type value out altogether (the reasons for which I will discuss at length
throughout this book). This means that your choices are limited with respect
to this utility right from the outset. For example, all live text functionality is
disabled in any file exported from KCC, so that there are no highlights or
annotations, no dictionary definitions, no search functions or bookmarks
available, not to mention Text-to-Speech. Moreover, it disables all active
hyperlinks (both internal and external) when you add Region Magnification
(i.e. Panel View), but disables two-page spreads when RegionMag is absent,
so that you can only have one or the other.
Second, it provides only the most basic text formatting options, via a Rich
Text Editor that doesn’t even allow for changing text alignment. Moreover,
while it supports embedded fonts, it does not actually display them in its
preview window, making it impossible to create accurate text layouts without
continually converting the file for export to Previewer. These are very basic
features that any graphic design program should have. They may be added or
improved at some point in the future, but at the time of writing this is not the
case.
The primary benefit of KCC is in the ease with which you can create pop-up
panels for Panel View. This can, in fact, be done automatically by KCC via
its “auto-detect” feature - so long as you have very clear, high-contrast
divisions between your panels (i.e. black borders on a white background):
overlaid or irregularly shaped panels, or those without sharply defined edges,
cannot be detected by KCC. However, creating manual pop-ups for
rectangular panels is fairly a simple process, since you can drag on corners to
resize and reposition any panel overlay.
Because of this, one use you might make of KCC is to set up your initial
Panel View layout, and then manually adjust the CSS code in the files it
creates. In fact, KCC has a built-in HTML/CSS editor that allows you to
make these changes right within the program, but unfortunately it does not
always display these changes accurately. But since KCC creates a complete
folder hierarchy on your hard drive automatically during the creation process,
you can access any of these directly at any time and alter them to suit your
needs.
22
The downside to this, however, is that KCC also adds some extraneous
elements to your code, and uses somewhat convoluted nomenclature for
many of its entries (mainly by adding something like “data-app-amzn-kecreated-” to the tags), making it more difficult to navigate and fine-tune your
work than if you wrote the basic code yourself (or modified it in a template).
You can clean up the KCC-created code fairly easily, but it’s still an extra
(and unnecessary) step.
But more importantly, it's actually just as easy to create the panels for
yourself using CSS values in the first place, as described in this guide, than to
go hunting through the gobbledygook spewed out by KCC. And that way you
have precise control over size and placement of the panels from the start.
Again, for any but the most basic layouts and functionality I don’t
recommend you use Kindle Comic Creator. But if you do, the information
given here will at least allow you to improve the code that it creates. See my
blog post post titled “Kindle Comic Creator Analysis” for a more thorough
evaluation of the reasons for and against using KC2.
23
3. Third-Party Utilities
I. KindleUnpack
In some instances it may be useful to know what’s happening inside your
Kindle file after it’s been converted (to see how much your images have been
compressed by Kindlegen, for example, or to see what code is being added or
altered). As mentioned, standard un-zip software will not suffice, as the final
Kindle file is no longer just a zip archive with a different extension, and
therefore cannot be extracted in the usual way. For this purpose a tool such as
KindleUnpack (formerly known as MobiUnpack) is required.
This is a python script (and thus requires Python to be installed), that creates
a decompiled archive of a Kindle file’s contents, allowing you to see what
changes Kindlegen has made. It is also useful to look at the code in other
ebooks that have features you might want to add to yours (such as drop caps
or floating sidebars, for example), to see how it is done. This is one of the
best learning tools available, although the code you’ll find is not always
pretty or easy to read (for the reasons mentioned above, among others). In
addition, you can only do this with unencrypted files; and, of course, the
contents of those ebooks are protected by copyright, so you can only look
and learn!
Bear in mind that KindleUnpack is not required for this tutorial, but its use
and purpose will be discussed here to some degree, along with a few of the
24
more interesting results that you may find.
II. KindleStrip
The file created by Kindlegen will always be much larger than the source
files from which it was created, and this invariably confuses those who don’t
know why. The reason is because the final Kindle file will include both a
KF8 formatted version of your ebook as well as a reflowable Mobi7 version
for backwards compatibility with older devices that do not support KF8 even if your ebook will never be available on any of those devices due to it
being a fixed layout file that they cannot display! Even though this function
of Kindlegen is intended as a support feature for reflowable files,it still
occurs during fixed layout conversions nonetheless, thereby creating a
bloated, bulky file.
Furthermore, in addition to both the KF8 and Mobi7 versions, the original
source files are also included in the final package as a zipped archive, just in
case Amazon needs them for re-converting later (in the case of software
updates, for example, as recently occurred with the increase in allowed image
size). However, it is important to be aware that only the portion relevant to a
customer’s device will be downloaded from Amazon to the user’s e-reader,
so the actual file size delivered will be smaller than the one created. This
“deliverable” file size is given in the Kindlegen conversion log, which we
will look at more closely later.
Of course, you may want to “strip” the file of this extraneous content
yourself if you plan to distribute it elsewhere, such as on your own website,
or through another retailer. KindleStrip is another python script that fulfills
this function, allowing you to remove all but the portion of the file that you
want. Again, this is not required for this tutorial, but is only mentioned here
as an available option, should you require it.
NOTE: Both of the above are complex programs and procedures intended for
advanced users only. I provide them purely for your information, and do not
cover their use in this tutorial, nor are they required to proceed. The links
provided lead to Wiki pages that detail their use and offer further resources to
assist you.
UPDATE: Amazon has added a new option to the Kindlegen conversion
process that allows you to keep the source files from being added to file in
the first place, making the use of KindleStrip less necessary. However, you
may still want to include them when you upload your file to KDP (if doing
so), but remove them for your own use. I'll explain how to use this new
option in the Conversion & Testing section. Because of this, however, it is
unlikely that KindleStrip will continue to be supported or updated.
25
4. Documentation
I. Kindle Publishing Guidelines
If you haven’t already visited the Kindle Format 8 page at Amazon it would
behoove you to do so, as it is the central hub for all things KF8, containing
links and information about the format. Along with a FAQ and forum, the
primary resource is the Kindle Publishing Guidelines, a pdf document
containing all the details Amazon has disclosed concerning Kindle ebook
code thus far. It is updated sporadically, as new features are included, and on
my blog I discuss these changes each time a new edition is released.
Sadly, there is both a wealth and scarcity of useful data in the Guidelines,
much of which is poorly written, some of which is contradictory, and none of
which is thorough, although most of it is critical to know. You’ll get all the
necessary portions here (and more), but I recommend you also read the
Guidelines for the official breakdown when you get a chance, and check for
updates from time to time, as they can contain both minor and very major
changes. That said, the somewhat sketchy documentation will make a lot
more sense once you’ve worked through this tutorial.
II. Samples
While you’re hanging out at Amazon be sure to download the free ebook
samples they link to on the KF8 page. These include both reflowable and
fixed layout samples, each of which can be downloaded separately, or all
together in a zip file from the “Samples” link. These contain both compiled
Kindle formats of the ebooks as well as all their source content, including
some informative notes within the code itself. At present, however, they are
rather out of date, and long overdue for an update to include new features.
26
The examples are instructive, if not always clearly explained. There is
nothing in them that you will not learn more clearly in this tutorial, and much
is missing that is given in great detail here, as well as in the templates.
III. Further Resources
As with most things, the Internet is filled with facts and fancies regarding
ebook formatting, some insightful, much confusing, and most awash with
errors. There are none that I know of regarding the KF8 fixed layout format
specifically that are worth visiting, although there is a great deal of
information to be found concerning the ePub standard upon which Mobi files
are based. A few of these stand out for their clarity or wealth of content, and
the primary ones among these are listed here for your reference.
Supported HTML5 / CSS3 tags - This is Amazon’s own page listing the
major elements of basic code supported in KF8. Though not exhaustive, these
are more than most content authors will ever need. The list is also included as
an Appendix in the Kindle Publishing Guidelines.
International Digital Publishing Forum (IDPF) - The central hub of the
committee tasked with developing and maintaining the ePub spec, on which
all major ebook formats are currently based, including KF8. Because of this
it is useful to know the actual code and its parameters, although much of it
does not apply since it is not supported in the Kindle format.
MobileRead Wiki - A platform for the discussion and dissemination of
information concerning ePub code and file structure, including many sample
files created to test out various elements that you can download. This is a
great way to learn how to code a specific element or feature of your ebook,
although again, it is only marginally applicable to Kindle files.
BISG Field Guide To Fixed Layout - A free ePub / PDF document that
discusses a wide range of issues dealing specifically with fixed layout
publications, from when and where to use them to the variations currently in
use and their major features. While it is a highly useful look at the state of
this niche in the industry, its depth can be summed up by the fact that the
Kindle format receives just slightly less than one page of analysis (out of 28).
#eprdctn - Twitter hashtag where ebook production issues are discussed, and
help can very often be found when you feel like you are drowning in a sea of
unfathomable code.
A number of other specific resources will be mentioned at the points in this
book where they are relevant. And, of course, be sure to follow my blog,
where you will find additional tutorials and discussions of ebook formatting
issues, digital publishing news, and updates to this book and the templates.
27
PART I: The File Structure
Before we can proceed to build our ebook file we need to know exactly what
it’s made of. Like nearly all ebooks today, Kindle fixed layout files are based
closely on ePub, with some additional code for Kindle-specific features, as
previously mentioned. Thus, we need to understand how ePub files are built,
and just what Amazon has added (or in some cases removed). As we progress
I’ll point out which is which, and what parts you can alter.
Incidentally, Apple’s fixed layout format for iBooks is also based on ePub with their own proprietary code included - so that much of what you learn
here can be used to make iBooks as well (to learn more about creating files
for iBooks there is a 7-part tutorial on my blog that shows you how in great
detail - just click the Tutorials tab). Thus, with some minor modifications, the
same file can be re-configured to meet ePub and iBooks specs, making it
readable on virtually any device with just a little tweaking.
If you have already read my iBooks tutorial then you will recognize much of
what is included in a Kindle ebook file when you open it, and you may also
notice that a few items are also missing. I will point out which features are
Kindle-specific and cannot be used in other ePub editions of your ebook, and
which ones are common to all.
In this tutorial, however, we are focusing entirely on Kindle fixed layout
ebooks, which can only be read by Kindle apps and tablets, so we will not
28
delve into any ePub code that does not apply to the Kindle format.
Opening the File
If you haven’t downloaded one (or both) of the Templates yet, then do so
now, as I’ll be using them to describe the contents of a standard Kindle fixed
layout file. Be sure to use the .epub version of the template for this tutorial so
that you can open it. The .mobi file is only there so you can view it in a
Kindle reader to see what each page is supposed to look like when complete,
and to try out certain interactive features. We’ll begin with the Simple
Template and progress to the more advanced version later.
As I mentioned earlier, an epub file is just a zip archive with its extension
changed. Consequently, you can open an epub the same way you open any
zip file, either by changing the .epub extension back to .zip and extracting the
contents, or by context-clicking on it (right-click or control-click, depending
on your system, hereafter referred to simply as a context-click without
distinction) and then selecting the option to open it with your zip tool of
choice. Depending on your settings you can often just double-click a zip file
to open it as well.
Most zip programs will add some options for creating and opening archives
to your context menu, or offer you the option to do so. If yours are missing,
you will want to (re-)install a zip program with these options selected. As
mentioned previously, 7-zip allows you to open an .epub as an archive
without changing the extension to .zip, which will save you a great many
steps along the way.
Once the archive is open or extracted you can context-click on a file and
select “Edit” to open it in your default text editor. Again, you can do this
from within the epub archive with 7-zip, edit the file in the default text editor,
and then save it, all without extracting and then re-adding the file to the
archive. But you can also work from an extracted (or newly created)
hierarchy on your hard drive, and let Kindlegen create the compressed
archive during conversion. Either way works just as well, so it’s really a
matter of personal preference.
IMPORTANT NOTE: Do NOT double-click the .epub file to “open” it, as
this will open the ebook in your system’s default ePub reader (or ask you to
select one), rather than as a collection of files contained within a zipped
archive. The .epub file will open as an ebook, by the way (or attempt to, at
any rate), but it will not display correctly, since it is formatted internally as a
Kindle file, but has not yet been converted into a Kindle file. Furthermore,
Kindle apps and devices cannot read epub files, and so “Kindle” will not be
one of your choices for opening the epub file as an ebook.
29
Inside the Template
When you look inside the template (or at the contents that have been
extracted) what you’ll see is two or three files and a number of folders (three
in the simple template and four in the advanced version), which look like
this:
content.opf
nav.xhtml (advanced template only)
toc.ncx
/css/
/fonts/ (advanced template only)
/html/
/images/
This is the basic file structure which makes up the basis of any Kindle file,
although there are endless variations, with either more or less content, and
it’s not always organized neatly into folders. Sometimes there are few (or no)
folders at all and everything is just lumped together into one big mess (this is
what you’ll find if you look inside Amazon’s own sample files, for example).
But I like to keep things tidy for ease of reference, and I recommend you do
so, too.
Here there is a separate folder for each type of file, plus two essential
“controller” files that contain the brains of the operation, telling the e-reader
what to do with the contents of the folders. If you look into each folder you
will see that each contains a number of files of the relevant type for that
folder’s name. We will look at each of these in turn.
30
One thing you will notice in the /html/ folder is that there is a separate file for
each and every page in the template. This is required for all fixed-layout
ebooks, regardless of the format, since by its very nature the content of each
page must be fixed, just as if you were designing it on paper or in a graphics
program. Even if your ebook consists of nothing but full-page images, each
one must be contained in a separate HTML file with precisely defined
dimensions, as if each one was a separate sheet of paper.
In many ways, Kindle files are easier to make than iBooks or other fixed
layout ePubs. If you have studied my iBooks tutorial, for example, you will
notice there are no mimetype or container.xml files here, nor are there /METAINF/ or /OEBPS/ folders either, all of which are required by all ePub
documents, including iBooks. While these must be manually created for
other fixed layout formats, the Kindle conversion process will create these
for you automatically. If you unpack a converted Kindle file, you will see
that these are all included in the final archive structure, even though you
didn’t put them there. So there are several pieces of the puzzle that you don’t
even need to know!
A Note On File Names: With one exception, the names of the files included
in the archive can be anything you like, such as mybook.opf or illustration1.jpg,
The exception is the cover.jpg file, found in the images folder, which is
required by Amazon in order to create the thumbnails that appear on Kindle
bookshelves. You cannot name your cover image anything but “cover” - not
the title of your book, not “my_book_cover” or anything else: it must always
be named “cover.jpg” if you want it to work correctly.
Other than this, you’re free to name your files whatever you like. So you
might have, for example, yourbooktitle.ncx or mystyles.css instead of what is in
the template. And, of course, there will very likely be a whole load of
additional files in each folder before you’re done, depending on the length of
your book. So I highly recommend naming your files either sequentially or
with some clearly descriptive titles that will make them readily recognizable.
If you look at the advanced template you’ll see that there are several files
inside each folder, including nearly a dozen CSS files and over twenty
images, as well as three different fonts and an HTML file for each of its
eighteen pages, the latter of which are all numbered sequentially. The CSS
files are each given numbers as well according to the page they are associated
with, aside from one general stylesheet that covers the first eight pages.
We will take a look at each of these files in due time. But first we need to
dive into the two operational files so that we can understand how a Kindle
ebook works and make a few informed decisions as we start our project.
31
The OPF File
This is the primary control center for your ebook, where the features that
effect the entire book are set, a detailed description is given, and all its
content is listed. Thus, it is often named content.opf, although as mentioned it
can be called anything, such as package.opf, which is fairly common, or the
title of the book, such as Amazon’s own Guide.opf. I find it easiest just to
keep the name consistent from project to project as content.opf so that I don’t
have to remember what it’s called when I go looking for it. You will be
accessing this file many times throughout the ebook creation process.
OPF stands for open packaging format, which refers to the ePub specification
that defines the structure and semantics of the package. But essentially it
contains a descriptive listing of the ebook’s physical contents; that is, the
actual component parts included in the archive, not its literary or artistic
content. In addition, it provides some crucial data specifying how the Kindle
software should display your pages, as well as providing a description of the
work itself, including author, title, and any other pertinent information.
This is the first of many files that need to explain some things to the
computer so that it understands exactly what it’s looking at and what to do
with all the information that we give it.
So go ahead and context-click on the OPF file of your choice and select
32
“Edit” or “Edit with...” to open it. What you should see is a page with
numbered lines in a basic system font. The OPF files in both templates
contain some added notes - the lines beginning with an exclamation point that are there to guide you and help to organize the contents so that it will
make more sense. In some cases, these notes are added at the end of a line of
code, making the line rather longer than it would be otherwise. Because of
this it will be easier to read these files if you maximize them to full screen.
The OPF consists of four essential sections, given in this order:
<Metadata>
<Manifest>
<Spine>
<Guide>
Preceding these at the top of the page you’ll see a few lines that are standard
coding declarations, stating what language we’re speaking (XML) and giving
a namespace reference (xmlns), which is a specific set of operating rules for
the reading system to follow.
In Kindle ebooks currently the primary code is based on ePub 2, with a few
new additions from ePub 3 (defined here by the version value), the standard
laid out by the IDPF (the International Digital Publishing Forum), which is
what this declaration namespace specifies. You will find similar instances of
this declaration in the NCX and at the top of every HTML file. Note that the
second line opens with a package tag that is not closed until the final line of
the OPF, since its entire contents make up the package, and are therefore
contained within these tags.
The only part you will need to alter here is the value of the very last element
in the package declaration, which is a unique-identifier. This value will be
referenced in the metadata section below, and will be discussed when we
reach that section.
33
1. METADATA
The first section of the OPF is where all the metadata for your ebook lives.
Metadata is “data about data,” and in ebooks it provides all the information
about the book itself - its title, author, publication date, etc. - which is used
not only by the reading device, but also by libraries, retailers, search engines
and other users to determine what the book is and how to catalogue it.
What you enter here will show up in databases as diverse as your local
bookstore or the Library of Congress (or Copenhagen, or wherever), as well
as Amazon and every other online ebook retailer you choose to distribute to.
The more metadata that you enter, the easier your ebook will be found, and
moreover, found by the readers who would most want to read it.
In addition to the standard ePub metadata that defines the ebook content,
Amazon has added its own set of data attributes that determine several
overarching functions of the ebook that make the Kindle fixed layout format
unique. For the most part, these operate as on/off switches for various
features, although a few have unique values that will be explained in detail as
we come to them.
Before we get to the metadata proper, however, we must first declare our data
reference systems, of which we’ll be using two. These you will find on the
first line of the metadata section:
34
<metadata
xmlns:dc=“http://purl.org/dc/elements/1.1/”
xmlns:opf=“http://www.idpf.org/2007/opf”>
The first of these, Dublin Core (dc), has provided the primary set of fifteen
metadata elements in use in ebooks for some time. But the second, slightly
newer Open Packaging Format (opf) set, from the IDPF’s own ePub spec,
adds some specifics to these that are useful for fine-tuning our statements, so
we declare both here. We will look at these further when we get to the
content metadata entries.
<!-- A Note Concerning Comments -->
As already mentioned, any text you see entered between angle brackets and
dashes with an exclamation point in front - such as those around the header
above this paragraph - is comment text, and is disregarded by the operating
system.
It is used to pass along useful notes or help to organize the content, both here
and in each of the HTML page files. In the templates I have used it to create
sections and sub-sections, and to point out important elements or options for
the entries.
You will find a similar convention in the CSS files, where forward slashes
and asterisks are used instead, like so:
/* comment */
In CSS files comment text also turns green, which is even more helpful for
pointing it out. But here in the OPF everything is black and white.
Any of these notes can be deleted or altered at your discretion, as they have
no functional effect on the file. Just be sure to delete both angle brackets and
everything in between!
35
<!-- Kindle-Specific Metadata -->
The first group of attributes in the metadata section of the templates are those
that pertain specifically to Kindle fixed layout ebooks (see Appendix B for a
complete list, along with their options). The first of these is the one that
makes the layout fixed, and is found at line 10 of the OPF:
<meta name=“fixed-layout” content=”true”/>
This tells the Kindle reading system to display the content exactly as defined
in the HTML and CSS files, and allows the use of absolute positioning in a
fixed page size. 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 user, 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 for the content value here, of course, is “true”, since if
you enter “false” then you are no longer making a fixed layout ebook, and
little else that follows in this tutorial applies. You may as well just leave the
36
fixed-layout value out rather than enter “false”, since in that case what you
have is a reflowable ebook. Hence, this is a required attribute for Kindle
fixed layout ebooks, and the only legitimate value is “true”.
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.
37
Next up is the orientation function:
<meta name=“orientation-lock”>
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”, the latter of which is the value that allows for autoreorientation. Another way of selecting “none”, of course, is just to leave the
orientation-lock attribute out altogether.
A new feature in KF8 called “PageID” allows for two-page spreads in
landscape orientation (which will be discussed in detail later), 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 almost
certainly change in future software updates, but how soon and on what
devices it will work is not yet known, so it’s something to take into
consideration at the moment when planning your layout. The table in
Appendix A details current support for this, and other features, and under
what circumstances they will work.
Another factor to consider is that the 10:6 and 16:10 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 (we will look
closer at this when we discuss image resolution).
Only the Kindle Fire HD 8.9” has a display size large enough to make twopage spreads truly effective at present, but designing ebooks for a single
model ignores too many potential readers to be a serious consideration.
Moreover, two-page spreads at present only work when certain other
conditions are met, limiting their usefulness a great deal.
38
A further difficulty with regard to auto-orientation will be encountered if you
choose to add Region Magnification panels to your layouts, since these only
work correctly in the orientation they were designed for.
Given these factors, it may be best to plan for single page displays for now,
whether portrait or landscape, although if you include auto-orientation now
you will not have to change it later when it is more broadly supported.
Whatever you decide, enter your chosen orientation mode 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.
118
5. Multiple-Image Pages
Each of the pages that we’ve looked at thus far - indeed, all the pages in the
Simple Template save two - include just a single image file. But as I
mentioned earlier, you can, in fact, add as many images to a page as you can
find room for, aligning them side-by-side using absolute positioning (you
can, of course, also layer them on top of one another, but that is a feature best
left for the Advanced Template).
To see how this is done, open up Page 9 of the Basic Template (09-studioleft.xhtml), where you will find two divs in the body of the document rather
than just one. Each of these contain the same new “halfpage” class for the
individual images they contain, which simply changes the 1280px height
value to one half of that, which is 640px, while maintaining the same full
width.
126
THE ADVANCED TEMPLATE
Now that we know how to build a basic fixed layout page filled with images,
we can begin to add more complex content to it. So far all our content has
been on one layer, either as a single image, or several images positioned sideby-side on the same layer, or “z-index.” We will now start adding additional
layers on top of this, using both text and images, and finally include the
magic code that will allow this content to be magnified, and even switched
with different content, by double-tapping on it.
For these examples I have tried to utilize the simplest HTML and CSS code
possible in order to achieve the desired results, while at the same time
making its use as clear and easy to understand as practical. This occasionally
results in repetitions and somewhat convoluted ways of doing things that
could be done with different, but somewhat less comprehensible coding. In
some instances code elements have been included that are not altogether
necessary, but are included to provide examples for future reference.
As with most things, there is generally more than one way to accomplish the
same goal, and writing code is as much an art as it is a technical achievement.
Learning as much as you can about the various ways of handling elements
128
FONTS
Stories are built on a foundation of words, and even illustrated books contain
a large amount of text. In reflowable ebooks the reader is allowed to alter
both the size and style of the chosen font in which those words appears. But
in fixed layout ebooks these options are removed, and the text is presented
with only the formatting that the ebook creator gives it. It is therefore
incumbent upon you as the designer to present your readers with text that is
both legible and visually pleasing.
Typography is an art with a long and illustrious history, and while not every
book demands a custom designed font in a unique style, the right typeface
goes a long way towards producing the right effect. Comics, for example,
customarily use a hand-written font type, but “Comic Sans” simply screams
out “lame” and “uncreative.” Many children’s books include basic sans-serif
fonts with broad, round glyphs for easy reading, although Dr. Seuss never did
so. You should give some thought to the typeface you use, whether it is
included within the image or as a separate text layer.
Live Text
Many of the comics and graphic novels currently available in the Kindle
format incorporate their text within the images, as part of the background art,
and a large percentage of children’s ebooks for the Kindle do so as well. This
makes sense for several reasons, not least of which is the added complexity
of creating separate text layers when compared to the relative simplicity of
producing image-only ebook files, but also because text has traditionally
been hand-inked directly onto the panel art of comics and graphic novels
until very recently.
Moreover, many fixed layout ebooks are designed and created first and
foremost with print in mind, and the digital publication is essentially an
130
Embedding Fonts
In order to ensure that the presentation of your text is consistent from one
Kindle device or app to another, you will want to embed any fonts you’ve
used for live text, with the exception of the default fonts already available on
the Kindle itself. However, there is considerable variation as to which ones
are included among the various devices, with Caecilia being the only one
currently common to all Kindles in production (besides the Kindle 3, which
lists no individual fonts, but only typeface styles).
Other fonts commonly included are Georgia, Palatino, and Baskerville for the
serif styles, with Lucida and Helvetica supplying the sans serif typeface on
most devices. Arial, Trebuchet, Courier, and Times New Roman appear only
on the first generation Fire, while the Paperwhite includes Futura and a
condensed version of Caecilia along with the normal one. Note that Comic
Sans is not included!
If the font you used for your design is not available, the Kindle system will
substitute a closely related variant, or one that is simply of the same “type”
(i.e. serif or sans serif). This will almost always result in text layouts that
vary to some degree from what you had intended, since no two fonts are
exactly the same size, due to differences in line height, weight, and spacing.
This will often cause the text to shift, or make a line break when it should
not, particularly if you do not add much leeway in your text boxes.
In general, if you’re using live text, it’s a good idea to include all fonts you
use, and to test your layouts on as many devices and apps as possible. But
also be sure to include a little extra end-line spacing just in case!
Before you include a given font in your ebook package, however, be sure to
check whether you have the right to use it. In fact, you should do this well
133
Text Shadows
While we’re on the subject of fonts, one further note must be made regarding
text formatting, and this pertains to adding shadows. You will see that nearly
all the text in the template has a drop shadow applied, and that the Kindle
renders it correctly. Thus, a quick lesson on adding text shadows is in order.
If you look at the first line of the default paragraph style in the stylesheet.css
file (line 62), you’ll find this code:
p { text-shadow: .02em .03em .05em #2a2a2a;
This creates the drop shadow that you see on all the text when browsing
through the template. It was added for the very purpose of showing how it’s
done, and once it was in there I had to use it everywhere just for the sake of
consistency. Let this be a warning: if you add a text shadow in one place, all
the other text will look thin and spindly by comparison!
There are four values appended to the text-shadow attribute, which specify the
following properties:
Value 1: X-Offset (horizontal)
Value 2: Y-Offset (vertical)
Value 3: Blur Radius (optional)
Value 4: Shadow Color(optional)
Positive offset values create down/right shadows, while negative values
produce up/left shadows. Positive values are by far the most common, but
don’t let that stop you from being creative!
The third value is the shadow falloff, which is the distance the shadow travels
before completely fading out. This is an optional value that allows you to
increase the shadow size, but which also makes it lighter as it spreads out,
giving it a thin and ghostly look rather than its default hard, dark edge. Note
that negative values are allowed! This makes the shadow spread contract, so
as to be smaller than the text that casts it.
Finally, the color value is also optional, with the default being pure black
(#000000), although this will show up as varying shades of grey, depending
137
PAGE LAYOUTS
We will now deconstruct the pages of the Advanced Template to reveal the
following aspects of Kindle fixed layout code:
1. Live Text Layers
2. Relative Positioning
3. Active Table of Contents
4. Positioning Text Boxes
5. Region Magnification
a. SourceId (Same Content)
b. TargetId (Alternate Content)
6. Alternate Text Positioning Tricks
7. MagTarget Background Fills
8. Image Switching Tricks
9. Panel View Layouts
10. Using a Target Parent
11. Lightbox Fills
Some of these span several pages of the Template, with a variety of examples
given, while some are contained on just one page. But the progression is
intended to be more or less logical, leading from one new function to the
next. However, there will inevitably be a bit of jumping around between the
various examples a certain points need making. In general, these are grouped
together and designed to build one upon the other; but again, each section is
intended to present a single subject as its primary lesson, beginning with the
most basic and working step by step through more complex examples.
138
1. Live Text Layers
Let us start with Page 3 of the Advanced Template. This page contains the
copyright information for the template, which includes a hyperlink to the
Creative Commons webpage, and consists of one background image with a
single overlying text layer.
The first thing to point out here is that this is live text, with a working
hyperlink. The same page in the Basic Template has its text embedded in the
image, and thus there is no active text link, nor can you interact with the text
in any way.
Conversely, if you tap and hold a word on the Copyright page of the
Advanced Template you will be presented with a pop-up box containing that
word’s definition, along with several further options for adding notes and
highlighting, searching for other instances of that term in the current book, or
on the Internet. Clicking on “Full Definition” will open the dictionary at that
entry, and then allow you to return directly to the book. And, of course, the
hyperlink will open the web browser and take you to that page.
140
/* GENERAL SETTINGS */
At the beginning of our stylesheet you will now see a section titled General
Settings, beneath which are our fullscreen divs in a subsection with the
heading Page Layout. A third entry has also now joined the two we’ve seen
before, this time adding another level of absolute positioning for our text:
.fullscreen div.txt {
position: absolute;
}
This builds on the preceding entry where a div within a div will use absolute
positioning; but here we’ve also added absolute positioning as the default for
any text within that nested div that has the txt class added. This is where most
of our text will live, and although some of that text will use relative
positioning - such as the centered text on the copyright and contents pages we can change the positioning to relative as needed.
141
/* FONT EMBEDDING */
Next we have a section for our Font Embedding information, as discussed
above. In this instance we are using three embedded fonts, each of which is
included in the /fonts/ folder. The first of these, Showcard Gothic, is our
header font, while Marker Fine Point is our primary text font. Lastly, I have
included a custom version of Wingdings3 from which I have deleted all but a
few of the characters using a font editor, and into which I have added a
couple of custom glyphs that I will point out later.
Incidentally, font files are relatively small, so including a whole font for just
a few characters is not a problem. But don’t go overboard and add in sixty
different fonts. It’s generally a good practice in page design to keep things
relatively simple and consistent throughout the layout. I have seen books in
which every paragraph used a different font, and needless to say it was a little
disconcerting. This can, of course, be an intentional effect, such as using
different handwriting fonts for a story told through a series of notes and
letters. But for the most, no more than half a dozen fonts should really ever
be needed.
142
/* TEXT FORMATTING */
Next is a section for Text Formatting, where all of our default text styling is
housed. Any HTML file that references this stylesheet will have these values
available for its content.
Notice that the first entry is for the body entity of the HTML page structure.
This means that anything on this page with have the values entered here by
default. Here we are using it to set up our base text styling, but you can use it
for other things as well. In this case we just want to define the primary font,
along with its default size and color.
body {
font-family: “Marker Fine Point”;
font-size: 300%;
color: black;
}
The body element does not require a class: since there can only be one body
section per page, the formatting is applied directly to it. Any styles added
directly to a base element, such as paragraphs or headers, will apply to all
instances of that element, unless overridden by a subsequent value.
The font-family value references one of the @font-face entries given in the
section above, and tells the reading system which font to render for any text
within that element. Since this is applied to the body, it becomes the default
font for all text on the page, unless another subsequent value overrides it.
Such is the case for the header entries, which can be seen if you scroll down
164
4. Stacking Text & Image Layers
We have already looked at pages 5-6 in the Basic Template section, so we
will pass over any further discussion of image embedding methods here,
since the basic code for these two pages is the same in the Advanced
Template as it is there. For a look at the two methods of inserting background
images illustrated by these pages, refer back to the Basic Template section
for these pages if you haven’t done so yet.
One new element, however, has been added to Page 6 in the Advanced
Template that is not present there. This is a layered dialogue balloon that uses
both a transparent gif and a text box, each on separate layers, stacked on top
of one another, and laid over the background image.
165
ALPHA CHANNELS
Text layers, by their very nature, have transparent “alpha channels” - that is,
the area not covered by the text itself is invisible, or “see-through,” allowing
the background color to show through. With images, however, this is
generally not the case. Instead, in most image formats any portions that
would be transparent are filled in with a white background.
This means that only square or rectangle images are possible in most formats.
This is not a problem when the background is also white; but if you want to
add a shaped layer over a background image, transparent alpha channels are
required.
There are several image formats where transparency is preserved, and
happily the Kindle format handles one of these. This is the .gif format. While
the .png format does preserve alpha channels, the Kindle format only
supports non-transparent PNGs. So for layering of shapes like dialogue
balloon or other cut-outs, you’ll need to use the .gif format.
Unfortunately, gifs can only handle up to 256 colors, and so are therefore a
poor choice for detailed artwork or photographs. But for vector graphics or
images that use fairly simple color palettes, this format can be surprisingly
crisp and bright. They are excellent for rendering colored pie charts, for
example, or tables containing text that are too complex to reproduce with
CSS.
One good use that you can make of gifs is for adding layered text balloons, as
seen in the example on Page 6 of the Template. These can either contain the
text within the image itself, or serve as a custom-shaped white background
for a separate text box layer, as is the case here.
180
1. MagTargets Using “SourceId”
The simplest type of zoom function is illustrated on Page 9 of the Advanced
Template, where the text box can be double-tapped to magnify the text to
150% of its default size. In this instance, the text content and styling remains
the same, but just gets bigger.
Double-tapping the zoomed region again dismisses it and returns the view to
normal mode. Swiping when the text is magnified advances to the next
magnified region, whether on the same page or another, which can be done
both forwards as well as back.
So let us look at how this is done.
Open the file for Page 9 (09-cartoon-left.xhtml), and note that the CSS link in
the head section now references a stylesheet that is specific to this page (09cartoon-left.css).
If you open up that CSS file you will find that the first 65 lines contain
“General Settings” entries that have been copied from the previous stylesheet
we’ve been using thus far. Notice that the CSS file for this page contains a
total of only 120 lines, half of which are new. This makes rendering this page
194
2. Alternate Content & Placement
Now that we have seen how to create a standard magnified text box, this page
gives a few unique examples of what you can do with this bit of code. The
tricks presented here are just a sample of the many uses you might find for
alternate content and text placement, and are limited only by your
imagination. We will see more examples in the later pages.
There are four tap targets on this page: two on the chalkboard, one over the
slate, and one contained within the text box at the bottom. Each of these
illustrates a different feature of the code, or demonstrates a use to which you
might put it.
This creates a fairly complex set of code in both the HTML and CSS files,
but if you break them down one at a time it’s no more complicated than the
ones we’ve looked at so far. In the HTML file for this page (11-textexampleleft.xhtml) I’ve added a comment above each section to make it easier to see
what each bit of code is for.
Note first of all that the background image for this page once again uses the
<div id> insertion method rather than the <img src> method used
predominantly throughout the template. This is done so that the background
image cannot be interacted with, since in this case we have intentionally
“hidden” the Tap Targets for the chalkboard example. Tap Targets are, of
201
3. Text Positioning & Alignment
Although this page is ostensibly concerned with text positioning it also uses
another method to replace the text content in the magTarget, which we will
look at in a minute. But first let’s talk about the default content on the page.
Note first of all when looking at the HTML for this page (12-textexampleright.xhtml) that we are once again using the <img src> insertion method for
the background, so that you can double-tap on any region not covered by text
and view the art in isolation, with pinch-and-zoom available for scaling.
After a simple, right-aligned text header, we find a single div container in
which four more divs have been embedded in a JSON object. This makes all
the text on the page - aside from the header - a single tap target covering the
entire bottom half of the page, all of which will disappear when doubletapped.
The CSS for this is found at line 94 of the stylesheet for this page (12-textexample.css):
#zoom {
position: absolute;
top: 45%;
left: 0%;
width: 100%;
207
4. MagTargets Using “TargetId”
The practice of using just the “targetId” rather than the “sourceId” to add
alternate content has already been explored in the previous few pages, so we
can dispense with that discussion here.
But just to quickly summarize, in case you skipped the preceding chapter, the
only time you need to use the “sourceId” element in the JSON string is when
you want to use the same default text content and styling for the magnified
content. Otherwise, the “targetId” can be used alone to create the Tap Target,
and the magTarget can be filled with anything you like.
Taking the concept of alternate magTarget content one step further, we have
in this page spread two instances of Tap Targets triggering an image to
appear, rather than a text box (or as part of a text box in the first case).
In the first example, on the left-hand page (13-studio-left.xhtml), we are still
using an anchored text container as our active link, just as we have before.
The dialogue balloon contains the JSON object, and thus provides the Tap
Target in the standard way.
Furthermore, we have already seen, in the example at the bottom of Page 11,
how to fill a magTarget container with a background image (in that case with
a parchment texture). That is all we’re really doing on this page as well.
216
5. Lightbox Fills Using TargetParent
We’re going to skip ahead for just a moment here in order to address a new
element that will be used extensively in the next page spread, and that is the
TargetParent. It will be easier to explain using this example, since that is
essentially all this page contains.
In the HTML file for Page 17 (17-lightbox.xhtml) the name for the “targetId”
value in the JSON object has been appended to read “zoom-magTargetParent”,
and this leads as usual to a div with this id that is its target:
In itself this is no different that what we’ve seen already. Where the
distinction lies is in the fact that the magTargetParent serves only as a host
for the divs that it contains. Each of these embedded divs can be formatted
individually, but the default visibility of both is controlled by their host
221
6. Panel View Using TargetParent
The two-page spread comprising pages 15-16 demonstrates how to create a
multi-panel image zoom using Kindle Panel View, with or without live text,
which has some unique features that set it apart from the examples we’ve
looked at thus far.
First of all, up till now we have only zoomed text, using the magTargets to
switch out images rather than magnify them. The purpose of this example is
to show you how to magnify an area of a background image, by creating Tap
Targets over a selected area, and zooming just that portion of the image.
Furthermore, some of these panels also contain live text layers: the text is not
embedded in the image, but consists of alpha channel gifs with text overlays,
so that all the interactive features of live text are present. In these panels
we’ll be magnifying both the text and image layers at the same time.
NOTE: It must be stated here once again that live text functionality is only
possible when no book-type is added to the OPF metadata section, and does
not work on the eInk Kindles in any case.
So let’s take a look at how to build a page containing panels. We’ll begin
with Panel 1 on Page 16, since it contains just an image (we’ll look at the
example on Page 15 in due course).
227
The Lightbox
Whereas in the previous example of a TargetParent (as used on Page 17 of
the Advanced Template) the lightbox was created at the same size as the
magTarget container in order to add a semi-transparent background to the
contents of the text box itself, here we want the lightbox to fill everything
except the magTarget region, so that the surrounding background will be
dimmed, and only the zoomed image will be clearly seen.
We do this by creating a lightbox that is the full size of the page, and filling it
with semi-transparent shade of dark gray rather than white (although, of
course, you can use whatever color you like). The div container is entered in
the HTML the same way as before (line 23):
<div class=“target-mag-lb”></div>
The styling for the lightbox class is found at line 77 of the CSS, in the
general “Region Mag Formatting” section that is used for every panel on this
page:
.target-mag-lb {
height: 100%;
width: 100%;
background: #333333;
opacity: .75;
z-index: 1;
}
228
Here we tell the lightbox container to fill the entire display, just like its parent
div, and give it a dark gray background fill (#333333) at 75% opacity (.75).
And once again we add a z-index value of 1 so that all content beneath it will
be dimmed.
If you were to convert and view the page at this point, what you’d see when
activating the magTarget is the entire page go dim as the lightbox fill
appears.
The Magnified Image
The last piece of the puzzle that we need to add, of course, is our magnified
image region. For this we add a second nested div within the parent
container, just below the lightbox div in the HTML (lines 24-26):
<div id=“zoom1-magTarget” class=“target-mag”>
<img src=“../images/panel-view.jpg” />
</div>
The first thing to note here is that we’re using the same image for the
magTarget as the background-image on this page. This is because the actual
size of the page images in this case is 1200x1920 (the resolution of the
Kindle Fire HD8.9) while the original-resolution value entered in the OPF
metadata is 800x1280 (the size of the Fire HD7 display), or one-third of its
actual size. In the Mag Regions we want to see it at full size (or one third
larger, at any rate). This method allows you to embed just one image, rather
than having to include the same image at different sizes.
235
The Text Layers
Now, just to make matters even more complicated and confusing, I’m going
to show you how to add live text layers to your magTarget regions.
We have already seen in the section for Page 6 above how to add an alpha
channel gif for the dialogue balloon, and the process is very similar here. The
primary difference, of course, is that we also want to magnify that content in
this example.
So the first thing to do is to embed the non-magnified version, just as we did
for Page 6. But in this instance we’ll put it in our JSON object in the primary
panel content section, the code for which is found at lines 31-38 of the
HTML for this page:
<div id=“zoom2”>
<a class=“app-amzn-magnify” data-app-amzn-magnify=‘{“targetId”:”zoom2magTargetParent”, “ordinal”:2}’>
<div id=“balloon2” class=“alpha2”></div>
<div id=“text2”>
<p class=“panel2text”>Lucyloo!</p>
</div>
</a>
</div>
So here we have our Panel 2 container, positioned using the “zoom2” id value
241
7. Full-Page magTarget Example
The final page of the Advanced Template is, in many ways, much simpler
than the previous five-panel layout of Page 17. In this example we will
exchange the entire contents of a page for a whole new set of elements,
including the full page background image and two text boxes with an active
hyperlink.
The basic page (18-magnified.xhtml) is constructed in the usual manner, with
an embedded background image and two div containers for the text.
The first of these text boxes (in the HTML page at line 17) holds the circular
balloon, which is created in the same way as the one on Page 12, except that
here we’ve used a class to add a white background-color and a bit of extra
padding to the bottom of the text to push it up a bit. Otherwise, this is really
just a simple text container, with no magnification functions added, as it will
be covered by the magTarget content anyway.
The second text container is where the action lies (lines 19-26 of the HTML).
Here we find our JSON object, which contains a basic magTarget value for
the “targetId” rather than a TargetParent reference. The default container holds
just one text box, with some standard text content for the note at the top of
the page.
244
PART III: Conversion & Testing
Once you have created at least one page of content, along with all the
necessary support files (OPF, NCX/NAV, CSS, images, etc.), you are ready
to convert your first test Kindle file. If you have created each of your
component files carefully, and listed them correctly in the manifest, the
chances are your ebook will work correctly on the first try and be fairly close
to what you’re after.
However, sometimes the resulting file simply will not work, or will be
broken in some unexpected way. In this case you will have to backtrack and
attempt to determine what went wrong and why, or return to an earlier
version that was working and start again.
This is why it is imperative to take your time and examine every line of code
as you enter it, and then again before you save and close each file. It can save
you endless hours searching for a missing semicolon or an unclosed tag
somewhere down the line.
245
Compiling The File
If you have created your content as an epub archive, either by using one of
the templates to add and edit your own content, or by changing the extension
of a zipped archive to .epub, then you are already set to go. Skip ahead to the
section on Converting The File.
If, on the other hand, what you now have is a lot of files and folders on your
hard drive, and you want to create a zipped archive, you have a bit of work to
do yet in order to prepare the files for conversion. Bear in mind, however,
that you do not have to do this, since Kindlegen will accept the OPF file as its
input. But if you want to produce an epub source file first (for upload to
KDP, for example), you will need to follow the next steps carefully.
All of the necessary files must be added to a zipped archive in the manner
described in the earlier section on Opening the Archive, and as seen in the
templates. That is, the top-most level - or “root” level - of the archive
structure must contain, at the very least, the OPF and any folders into which
you have added support content.
All of your files can, in fact, be dumped together into the root level of the
archive if you so choose, or you can order them in any way you like, so long
as the location or every file is recorded correctly in the manifest section of
the OPF so that the reading system knows where to find them. Only the OPF
itself is required to be at the root level.
Word of Warning: Do not move your content files around once you have
added them to your archive or file hierarchy, since this will break any links
that lead to them, and you will have to go back through all your files to find
every reference and fix it. For this reason, if no other, you should organize
your content from the start in a clearly logical manner.
247
Converting The File
Amazon provides three different ways to convert your compiled epub archive
into a Kindle ebook file, but there is really only one primary choice that you
need consider, and that is Kindlegen.
The other two options are the Kindle Previewer and the KDP upload portal,
both of which have several major shortcomings that make them difficult and
inefficient to work with, although this will depend to some degree on what
you want and how complex your project is. To some extent it is also a matter
of preference, so we’ll look at all three.
Kindle Direct Publishing
When you set up your title on KDP you will be given the opportunity to
upload your unconverted source file, upon which it will be converted into a
Kindle ebook. KDP accepts many source formats, including EPUB, HTML,
249
Kindle Previewer
The Kindle Previewer serves two separate functions, with varying degrees of
success. First, it provides a graphic user interface for Kindlegen, which is the
program that performs the actual conversion behind the scenes. Kindlegen
itself is a command-line program that at first may seem somewhat daunting
to use, since we are all more or less accustomed to point and click
interactivity. In many ways, Previewer is easier to work with for this reason,
although it has some drawbacks as well.
Secondly, as its name suggests, Previewer allows you to view your converted
Kindle ebook as it would appear on a wide range of devices. A drop-down
menu on the home screen allows you to choose your preferred device as the
default, and lists the models currently supported by the emulator:
251
Kindlegen
The workhorse of the Kindle conversion pipeline, Kindlegen will become
your best friend and ally in the process of turning hard work into literary art.
While at first this command-line interface might seem foreboding, and even
clunky, it is, in fact, highly efficient and simple to use, providing all the
information you will need to repair any errors and determine exactly what is
happening to your files during the conversion process.
Once you download and install Kindlegen you will want to put the primary
program file (kindlegen.exe) in an easy to access location. I suggest you
place it in the main C: drive root directory, or just one subfolder down (such
as C:/Kindlegen), and use this for all your conversion activities.
The reason for this is that you cannot simply double-click on the Kindlegen
executable to run the program. Instead, you must run it from the Command
Prompt in Windows (Windows > System32 > cmd.exe) or in Terminal on the
Mac (Applications > Utilities > Terminal.app). In Windows this can also be
accessed via the Start > All Programs > Accessories menu. I highly
recommend you add a shortcut to this either on your main Start menu or your
desktop for ease of access, as you’ll be using it a lot.
When you open the Command Prompt what you’ll get is an old-school MSDOS style terminal where you type in the “commands” you want to run:
As you can see in the screenshot above, you can change the default drive and
file location using the cd (change directory) command. Here I’ve changed it
to the main C:/ drive where my kindlegen.exe program is living. You can, of
course, run this from anywhere. You may, for example, want to create a
dedicated folder just for your conversions, and run Kindlegen from there
259
KINDLE UNPACK
While the Kindlegen log shows the percentage of compression applied to the
text content, the only way to see how much your images have been
compressed is to unpack a converted file and look at the image file sizes.
KindleUnpack (or MobiUnpack as it used to be known), as mentioned in the
Tools section of this book, is a Python script that allows you to do just that.
You simply double-click the script to launch the graphic interface, then enter
the location of the mobi file to be unpacked and the output location where
you want the file’s contents to be extracted.
You do not need to worry about any of the checkboxes unless you’re doing
more advanced analysis procedures.
Check the "Split Combination Mobi Files" box, for example, to have the
script attempt to recreate the compiled mobi7 (.mobi) and KF8 (.azw3) ebook
files produced by Amazon for delivery. This does not always work correctly,
as Amazon are always modifying their internal process, and do so differently
for different devices, but it will give you a good idea of the actual file sizes
involved. I do not recommend distributing either of these resulting files
without thoroughly testing them first. In fact, you are safer just delivering the
mobi file with the source archive removed.
Click “Start” and in a matter of a few short moments the file’s contents will
be successfully unpacked.
262
Testing The File
Now that you have a converted Kindle ebook, you will need to test it
thoroughly to be sure it’s working properly. You can, of course, look at the
converted file in the Kindle Previewer, using its various device emulation
modes to see how it looks on different readers. We have already discussed
Previewer’s shortcomings, but you may find it works well enough for you,
and provides as much testing as you need.
The obvious drawback to this approach is that none of your readers will be
viewing your book that way, and so at best it’s only an approximation of
what the end user will see. To be certain that your product is functioning
correctly and at its optimal best you will need to test it on at least one actual
Kindle app or device, and preferably more than one. For this a device is
better than an app, as the latter do not function in the same way, and
generally have fewer features.
The quickest and easiest (as well as cheapest) way to do this is to install the
free Kindle app on your computer. Once installed all you have to do is
double-click on the converted Kindle file and it will open in the Kindle
desktop application, where you can scan through the pages, test the zoom
functions and links, and see how your page layout actually appears when
rendered. Be sure to click on every link and test out every feature that you’ve
added so there are no harsh surprises down the line when customers can’t get
something to work.
264
Above is a shot of my current ebook testing setup. It is admittedly a bit
excessive, but I share it to make the point that you can never test a file too
much, only too little. It is also very helpful to have multiple devices side-byside so that you can see exactly where things are working properly and where
they are not.
But so long as you can get your book to work on at least one primary Kindle
device you should be more or less good to go.
A few additional points should be made here with regard to the Kindle testing
process.
First, when transferring (side-loading) files to the Kindle devices you will
find them on the Docs tab rather than in Books, since they are then
considered personal documents. This is due to a shortcoming in Kindlegen
(intentional or otherwise), which does not allow for the addition of the EBOK
metadata value that creates this distinction:
<meta name=“CDE Type” content=“EBOK” />
This meta entry will be added to your ebook when the file is uploaded to
KDP and put on sale, so if you download that file and load it onto your
Kindle it will appear in the Books tab as it should. But any other files that
you side-load are considered personal documents and will appear in the Docs
tab instead.
As a side note, if you do go ahead and enter this value in your OPF manually,
Kindlegen will not only ignore it, but will, in fact, actually delete the entry!
268
1. KINDLE APPS & E-INK SCREENS
FUNCTION
Booktype
1. Page-Spread
Comic
Children
None
2. Virtual Panels
Comic
Children
None
3. Letterbox Color
Comic
Children
None
4. HTML Image Zoom
Comic
Children
None
5. HTML Cover Doubling
Comic
Children
None
6. TOC Menu Link
Comic
Children
None
7. Bookmarks
Comic
Children
None
1
PC ANDROID KINDLE PAPER
WHITE
APP
3
APP
No
No
No
Y/N 1
No
No
No
No
No
Yes 2
Yes2
Yes2
No
No
No
Y/N 3
No
No
No
No
No
Y/N3
No
Y/N3
Choice
Choice
Choice
B/W 4
White
White
White
White
White
White
White
White
No
No
No
Y/N 5
Yes
Yes
Yes 6
Yes6
Yes6
Yes 7
Yes7
Yes7
Y/N 8
Y/N8
Y/N8
Y/N8
Y/N8
Y/N8
Y/N8
Y/N8
Y/N8
Y/N8
Y/N8
Y/N8
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
Y/N 9
No
Yes
No
No
No
Yes
Yes
Yes
Yes when RegionMag is absent, No otherwise. All page spreads have inner margin removed,
regardless of Spine property value. This is the only instance in which a fade is used for page
transitions rather than scrolling.
2
All spreads are two-page when RegionMag is absent, but correct otherwise; inner margins are
correct in all cases.
3
Virtual Panels active only when RegionMag code is absent.
4
Black when RegionMag is present, White otherwise.
5
Pinch & Zoom available only when Virtual Panels are active.
6
Zoom function available via magnifying glass icon.
7
Pinch & Zoom available for all pages, and without tapping, regardless of image insertion
method.
8
Yes when NAV is present, No otherwise, as the HTML cover page is then suppressed by
KindleGen.
9
Bookmarks only active when RegionMag code is absent.
269
8. Live Text Functions
Comic
Children
None
9. Hyperlinks
Comic
Children
None
10. Layout-Blank
Comic
Children
None
10
Yes
Yes
Yes
No
No
Yes
No
No
No
No
No
No
Yes
Yes
Yes
Yes
Yes
Yes
No
No
No
No
No
No
P* 10
P* 10
P* 10
! 10
! 10
! 10
P*10
L*10
L*10
P/L10
L10
L10
L: Appears in Landscape mode.
P: Appears in Portrait mode.
X: Page does not appear in either mode, and can only be accessed via a menu link when in
landscape mode.
!: In both modes the page is visible when scrolling forward, but after scrolling two or more
pages forward and then back again the page is absent; if only one page forward has been
turned the page is still present when scrolling back. There is a delay as the system tries to
access or bypass the page.
*: Only viewable orientation on this device.
270
2. KINDLE COLOR LCD DISPLAYS
FUNCTION
Booktype
1. Page-Spread
Comic
Children
None
2. Virtual Panels
Comic
Children
None
3. Letterbox Color
Comic
Children
None
4. HTML Image Zoom
Comic
Children
None
5. HTML Cover Doubling
Comic
Children
None
6. TOC Menu Link
Comic
Children
None
7. Bookmarks
Comic
Children
None
1
FIRE FIRE
(GEN1) (GEN2)
HD7
HD8.9
No
No
No
Y/N 1,2
No
No
Y/N1,2
No
No
Yes 2
No
Yes
No
No
No
Y/N 3
No
No
Y/N3
No
No
Y/N3
No
No
White
White
White
Black
White
White
Black
White
White
Black
White
White
No
Yes
Yes
Y/N 4
Yes
Yes
Y/N4
Yes
Yes
Y/N4
Yes
Yes
Y/N 5
Y/N5
Y/N5
Y/N5
Y/N5
Y/N5
Y/N5
Y/N5
Y/N5
Y/N5
Y/N5
Y/N5
Yes
Yes
Yes
Yes 6
NONE 7
Yes 8
Yes6
NONE7
Yes8
Yes6
NONE7
Yes8
No
No
Yes
No
No
Yes
No
No
Yes
No
No
Yes
Yes when RegionMag is absent, No otherwise.
All page spreads have inner margin removed, regardless of Spine property value.
3
Virtual Panels active only when RegionMag code is absent.
4
Pinch & Zoom available only when Virtual Panels are active (i.e. RegionMag 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.
5
Yes when NAV is present, No otherwise, as the HTML cover page is then suppressed by
KindleGen.
6
Only the Go To option available, either in the top or bottom menu, depending on whether
RegionMag code is present.
7
The entire menu is absent, so no navigation links are available at all.
8
Bottom menu contains Search option, while a top menu contains Settings (inactive), Go To...,
Notes, and Bookmark options.
2
271
8. Live Text Functions
Comic
Children
None
9. Hyperlinks
Comic
Children
None
10. Layout-Blank
Comic
Children
None
9
No
No
Yes
No
No
Yes
No
No
Yes
No
No
Yes
Yes
Yes
Yes
Y/N9
Yes
Yes
Y/N9
Yes
Yes
Y/N 9
Yes
Yes
P/L 10
P/L10
P/L10
X10
X10
X10
X10
X10
X10
L10
X10
L10
Both internal and external hyperlinks are active only when RegionMag is present.
L: appears in Landscape mode / P: appears in Portrait mode / X: page does not appear in
either mode, and can only be accessed in landscape mode via a menu link.
10
272
ANALYSIS
1. Page-Spread
A new function in KF8 is the “page-id” Spine element which purportedly
allows for the creation of two-page spreads in landscape mode (either with or
without a margin in between). As you can see from the chart, this is 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
“RegionMagnification” 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, two page spreads are only available in
comics that consist only of images, with no Panel View 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.
One surprising fact here is that the Paperwhite actually supports Page-Spread
in all book-types. 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. Just as interesting is the fact that, while the
Kindle 3 does not support Page-Spread, it does default to landscape
orientation for the book-type 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.
2. Virtual Panels
This new 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.
280
APPENDIX B
Kindle Metadata Attributes
Metadata
Values
Layout can be specified using one of the
following metadata fields:
Required.
1) Kindle Method
<meta name=
“fixed-layout” content=“value”/>
true, false
Default is false.
2) EPUB3 Method
<meta property=
“rendition:layout”
>value</meta>
pre-paginated,
reflowable
Default is reflowable.
Orientation can be specified using one of the
following fields:
portrait, landscape, none
1) Kindle Method
<meta name=
Default is none.
“orientation-lock” content=“value”/>
2) EPUB3 Method
<meta property=
“rendition:orientation”
>value</meta>
portrait, landscape, auto
Default is auto.
<meta name=
“original-resolution”
content=“value”/>
Required. Identifies the original
design resolution and aspect ratio
of the content in pixels (i.e.
1024x600).
true, false
default is false.
<meta name=
“RegionMagnification”
content=“value”/>
<meta name=
“primary-writing-mode”
content=“value”/>
horizontal-lr
horizontal-rl
vertical-rl
vertical-lr
Default is horizontal-rl.
<meta name=“book-type”
content=“value”/>
Required for comic,
optional otherwise.
children, comic
<itemref idref=“page-id”
properties=“value”/>
Required for comic, optional
otherwise.
Not technically a metadata value, this is entered
as an item attribute in the spine entry of a given
page-spread-left
page-spread-right
281
page.
facing-page-left
facing-page-right
layout-blank
Default is layout-blank.
282
APPENDIX C
Standard Metadata Attributes
Property
Description
contributor
Used for persons making contributions to the publication in a
manner that is secondary to the role of creator, such as editors,
translators, or designers. The significance of the role is arbitrary,
as, for example, an illustrator may be a primary creator or a
secondary contributor. The semantics and attributes are the same
as those used for creator.
coverage
Identifies the spatial or temporal topic of the publication, such as
the geographic applicability of a resource or jurisdiction under
which it is relevant. Spatial coverage refers to a physical region,
using place names or coordinates, while temporal coverage
specifies a time period covered by the content, such as Neolithic or
Elizabethan. See the DC Coverage Element for further descriptive
commentary.
creator
The primary authors or creators of the publication, whether person,
service, or organization. A separate element should be used for
each name, and these should be given in the order to be presented
to the reader. The OPF 2.0 spec adds the optional attributes role
and file-as. See MARC Code List for Relators for complete list of
the 223 role values and their 3-character codes, along with a
description of each role’s function.
date
Any relevant date(s) for the publication, such as creation,
publication, and/or revision. The OPF spec adds the optional
event attribute to define these temporal points, using standard
defined Date & Time Formats (i.e. YYYY-MM-DD), of which the 4digit year is required (this is not required by Amazon, although it is
recommended). A full set of event values has not been defined.
description
The description(s) of the publication content. This may include, but
is not limited to, an abstract, table of contents, graphical
representation, or free-form account of the content. It is often
used to provide the sales copy for online retailers, as well as book
reviewers and bloggers.
format
The media-type or physical dimensions of the publication. This
might also include such factors as duration, software version, or
operating system, along with hardware required to use the
resource. The recommendation is to use a MIME type.
identifier
Required. One or more unique references to the publication
within a given context, such as ISBN, DOI, URN, URI or URL. The
OPF spec provides an optional scheme attribute that names the
system or authority that generated the identifier, although no
specific schema are endorsed or defined as required. One element
must be defined as the unique-identifier, with an id value
283
specified.
language
Required. One or more language identifiers, with optional region
subtag, such as en-gb for English as spoken in Great Britain, or
fr-ca for Canadian French. Avoid using subtags unless necessary.
The OPF spec requires that these conform to RFC 3066 or its
successor.
publisher
The publisher(s) of the resource, defined as the entity responsible
for making the publication available in its present form, such as a
publishing house, university department, or a corporate entity. This
is generally the entity to whom the ISBN is registered (the
“publisher of record”).
relation
Identifies related resources and their relationship to the current
publication. Used to express linkages between entities, such as
soundtracks to a movie, or reference works dependent on support
materials. There is no standard schema adopted.
rights
An assertion of the rights held by the publisher/creator with
respect to the publication and its content. A statement of Copyright
notice should appear, including Intellectual and other Property
Rights, as well as links and/or references to the rights protection
system or service employed.
source
Identification of primary or secondary resource documents or
publications from which the current publication is derived, either in
whole or in part, including necessary discovery metadata.
subject
The topic or subject matter of the content. This can be anything
from one or more keywords, classification codes such as those
provided by the Library of Congress or BISAC’s Subject Headings,
or any descriptive phrase. There is no schema standardization
provided.
title
Required. There must be at least one title for the publication,
although multiple titles and/or subtitles are allowed, such as for
series or volumes. The first one listed should be the primary title.
type
The nature or genre of the publication. Includes terms for general
categories (such as Fiction or Non-Fiction, etc.), genres (such as
Young Adult, Fantasy, Romance), as well as those describing
functions (such as Technical Report or Dictionary). To describe the
physical medium or coding mechanism of the resource, use the
format element.
284
APPENDIX D
Device Display Resolution
DEVICE
Kindle e-Ink [6”]
Kindle Paperwhite [6”] (e-Ink)
Kindle Fire (1st gen.) [7”]
Kindle Fire (2nd gen.) [7”]
Kindle Fire HD 7”
Kindle Fire HD 8.9”
Kindle Fire HDX 7”
Kindle Fire HDX 8.9”
Resolution
800x600
1024x758
1024x600
1280x800
1280x800
1920x1200
1920x1200
2560x1600
PPI / Total Pixels
167ppi - 480,000
212ppi - 776,192
169ppi - 614,400
254ppi - 1,024,000
216ppi - 1,024,000
254ppi - 2,304,000
323ppi - 2,304,000
339ppi - 4,096,000
Aspect
4:3
4:3 *
10:6 **
16:10
16:10
16:10
16:10
16:10
Kobo
Kobo
Kobo
Kobo
Kobo
Kobo
Kobo
Kobo
800x600
800x600
1024x758
1440x1080
1024x600
1280x800
1920x1200
2560x1600
200ppi
167ppi
213ppi
265ppi
169ppi
215ppi
323ppi
300ppi
4:3
4:3
4:3 *
4:3
10:6 **
16:10
16:10
16:10
iPad 2 [9.7”]
iPad 3-5 [9.7”]
iPad Mini [7.9”]
1024x768
2048x1536
1024x768
132ppi - 786,432
264ppi - 3,145,728
163ppi - 786,432
4:3
4:3
4:3
Galaxy
Galaxy
Galaxy
Galaxy
1024x600
1280x800
1280x800
1280x800
171ppi
169ppi
163ppi
149ppi
10:6 **
16:10
16:10
16:10
Google Nexus 7”
Google Nexus 7” (2nd gen.)
Google Nexus 10”
1280x800
1920x1200
2560x1600
216ppi - 1,024,000
323ppi - 2,304,000
300ppi - 4,096,000
16:10
16:10
16:10
Nook
Nook
Nook
Nook
800x600
1024x600
1440x900
1920x1280
167ppi
169ppi
243ppi
256ppi
4:3
16:10
16:10
3:2
Mini [5”] (eInk)
Touch [6”] (eInk)
Glo [6”] (eInk)
Aura HD [6.8”] (eInk)
Vox [7”]
Arc [7”]
Arc HD7 [7”]
Arc HD10 [10.1”]
Tab 7”
Tab 8.9”
Note 8”
Note / Tab 10.1”
(eInk)
Color/Tablet
HD 7”
HD+ 9”
-
-
-
480,000
480,000
776,192
1,555,200
614,000
1,024,000
2,304,000
4,096,000
614,400
1,024,000
1,024,000
1,024,000
480,000
614,400
1,296,000
2,457,600
Microsoft Surface RT [10.6”]
1366x768
148ppi - 1,049,088
Microsoft Surface Pro [10.6”]
1920x1080
224ppi - 2,073,600
* 10 pixels narrower than full 4:3 ratio
** Actual ratio is 128:75 = 10.24:6 - or 16:9.375 (i.e. 17:10)
16:9
16:9