R. Scot Johns's Blog, page 8

March 24, 2013

Kindle Fixed Layout Tutorial - Part 11

PAGES

Having gotten the support files out of the way, we can now turn our attention to the actual pages of the ebook. From this point forward we will be examining each page of the Basic and Advanced Templates, beginning with the simple image-only content and progressing in stages through increasingly complex layouts, complete with overlays and zoom functions.

Before we begin a short prologue is in order regarding the files required to create the page layouts themselves. As mentioned previously, each page in a fixed layout ebook is contained within a separate HTML file, formatted to the size of the default display as discussed in the section on images above. We will see how this is done in a moment.

The HTML file contains all of the text for that page, and/or links that tell the reading system which images to insert into that page (if any). Each of these content elements are enclosed within a variety of “containers” that can be sized and styled and placed into position using class and/or id tags, such as:

<div id=“container1” class=“fullpage”>

Some content goes here.

</div>

The div is a “division” of the content that functions as a container for that section of content, and can best be thought of as a text box, although it can contain images as well, and even other divs within it. In this way you can visualize each page as a series of containers within containers, each with a definable height and width, and which can be placed precisely on the page. The page itself consists of an all-encompassing div that contains all of the other elements on that page.

We will spend nearly all the remainder of this book looking at the various content elements in a Kindle fixed layout ebook and how to place them on the page. However, before getting to that content, a few things should be pointed out here with regard to how HTML code works for those who have never used it before, since I must assume there will be some of these among the readers of this tutorial. Many lengthy textbooks have been written on the subject, but a few basic facts are all that are required to begin.

Firstly, each of the attribute tags that surround the content elements in an HTML file are references to an entry in the related CSS file that determines how that content should be styled, which includes all aspects of its visual presentation. CSS stands for Cascading Style Sheet, and is a secondary document, or set of documents, that contains all the styling data for these tags. The relevant CSS is referenced from each HTML file, so that the reading system knows where to look for this information.

If you look inside any of the HTML files contained in either of the templates, or in any ebook file, you will see there are two main sections below the namespace declaration: a <head> section and a <body> section. In the <head> section you will find a line containing the <title> (where you simply enter the title of your publication), a <meta> entry which gives the encoding information for the content, telling the reading system what it’s looking at (you don’t need to change anything here), and finally a <link> to the CSS file, such as:

<link rel=“stylesheet” href=“../css/stylesheet.css” type=“text/css” />

The three attributes may be in any order, but each must be present. The only one you need to change, however, is the href defining the link, or location, of the css file. In this case the ../ portion tells the system to begin looking for the file at the root level, since this particular file is in a neighboring branch folder labeled css.

A second general point to make concerns the difference between the class and id tags. These are often confused, and even used interchangeably, but in proper usage the id tag is used to “identify” one specific instance of an element, such as a particular div on a page, and consequently are generally used in fixed layouts to define the size and position of a given element, rather than its visual style (although they can contain some, such as when there is no need to create a whole new class for just that one instance). Conversely, class tags can be applied to any number of elements, and thus contain general styling data, such as color and weight for text, or border style and background-color for containers.

Inside the CSS file you will find something called a CSS Reset. This is a long string of common code elements set to a default neutral value. This is done so as to override any inherent browser settings that might be added if the file is opened in a third-party reader, since many browsers include their own default values. This sets everything to zero so that nothing goes awry. There are many CSS Resets that can be found online, but in Amazon’s samples they include the one from Yahoo! that is found in both of the templates.

Finally, with regard to positioning in fixed layouts, you must use absolute positioning for all divs in order to affix their position, but the content within those containers can have relative positioning, as, for example, to center align a block of text, which can only be done using relative positioning (since its position is inherently relative to the borders on either side). You can, of course, also use absolute positioning for content within a div. We will see a variety of ways to do this very soon, but be aware that this is very often an attribute that trips up even seasoned formatting veterans, since it can throw off everything with wildly unexpected results! If things are just not showing up where they should be, go back and check your positioning values. Chances are you’ll find one that should be the other.

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on March 24, 2013 17:30

February 18, 2013

Kindle Fixed Layout Functionality [UPDATED 2-18-13]

Before we dive into the next portion of the tutorial, I thought it would be useful to post the following chart which comprises Appendix A of the ebook. This information will be discussed thoroughly and referred to throughout the tutorial, so having it beforehand might be helpful (especially since the ebook isn't out yet). And since much of it will make no sense without some explanation, I will provide a short introductory breakdown here as well. This will get a little technical, and may well make no sense at first for some of you (if so, just skip it for now and refer back when necessary), but it will all become clear in time. First, the chart...

Function

               Booktype

Kindle

3

Paper

white

Fire

(Gen1)

HD7

HD9

PC

app

Android

app

1 - Page-Spread

               Comic

               Children

               None

N/A

No

No

Yes

Yes

Yes

No

No

No

Yes

No

No

Yes

Yes

Yes

No

No

No

Yes

No

No

2 - Letterbox Color

               Comic

               Children

               None

White

White

White

White

White

White

White

White

White

Black

White

White

Black

White

White

Choice

Choice

Choice

White

White

White

3 - Virtual Panels

               Comic

               Children

               None

No

No

No

Yes

No

Yes

No

No

No

Yes

No

No

No

No

No

No

No

No

Yes

No

No

4 - HTML Image Zoom

               Comic

               Children

               None

"Yes"

"Yes"

"Yes"

"Yes"

"Yes"

"Yes"

No

Yes

Yes

No

Yes

Yes

No

Yes

Yes

No

No

No

No

Yes

Yes

5 - Cover Image Access

               Comic

               Children

               None

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

6 - Cover Doubling

               Comic

               Children

               None

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

7 - TOC Menu Link

               Comic

               Children

               None

No

No

No

No

No

No

Yes

Yes

Yes

No

NONE

No

No

NONE

No

Yes

Yes

Yes

Yes

Yes

Yes

8 - Bookmarks

               Comic

               Children

               None

No

No

No

Yes

Yes

Yes

No

No

Yes

No

No

Yes

No

No

Yes

Yes

Yes

Yes

Yes

No

Yes

9 - Live Text Functions

               Comic

               Children

               None

No

No

No

No

No

No

No

No

Yes

No

No

Yes

No

No

Yes

Yes

Yes

Yes

No

No

Yes

10 - Hyperlinks

               Comic

               Children

               None

No

No

No

No

No

No

Yes

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

11 - Font Embedding

               Comic

               Children

               None

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Each of the 11 rows features one functionality element in KF8 that I have tested on the devices and apps listed in the five columns to the right. These are (in order): the Kindle for PC desktop application, a first generation Kindle Fire, the new Kindle HD 7" and HD 8.9" devices, and the Kindle for Android app. Unfortunately, I do not have a second generation Kindle Fire to test, nor a Mac on which to test the Kindle for Mac desktop application. And, of course, as mentioned in the Introduction, fixed layout files cannot be tested in the Kindle for iOS/iPad app, since transferring them in any way I have attempted (Dropbox / DiskAid / Send To Kindle) actually breaks the file. I didn't bother testing these on my Paperwhite or Kindle 3 keyboard model, since comics and graphic novels on these devices are pointless, even though technically they now support the format [see Update below].

As mentioned previously, there are two official book types for Kindle fixed layouts, defined by the appropriately titled "booktype" metadata value in the OPF file (to be discussed in an upcoming section), these being "children" and "comic." But, of course, you can also enter "none" (or simply leave it out), making essentially a third practical booktype. Unlike all the other Amazon-specific metadata values, which determine functionality for a specific listed attribute (such as fixed-layout or orientation, for example), the "booktype" attribute effects a broad range of overall ebook functionality - none of which is detailed by Amazon in their documentation. Hence, this chart. In it, each of the listed functions has been tested with each of the three booktype values set.

In addition, each of the three was tested with the RegionMagnification set both to "true" and to "false," since Amazon states in the Kindle Publishing Guidelines (Section 5.7) that the new Virtual Panels feature (row 3) is reliant upon this setting. This does not prove to be the case, as thorough testing resulted in no change whatsoever in the Virtual Panels functionality with either setting on any device or app. This, of course, may change in future updates, and I will update the chart accordingly at that time. But I have made no note of this distinction in the chart at present, since there is none.

Also, I should point out that in every case changing the booktype made no difference to the functionality of the Kindle for PC app, which appears to simply ignore the setting.

I have entered bold text for the results that stand out as the exception to the rule in order to make the disparity more readily apparent at a glance, and to point out issues with the functionality.

In addition, Appendix A provides no test results for region magnification features (aside from the new Virtual Panels function), as this is contained in Appendix B, and will be dealt with in the latter, more complex portions of the tutorial.

And now the breakdown...

1. Page Spread

A new function in KF8 is the "page-id" spine element which (purportedly) allows for the creation of two-page spreads in landscape mode (either with or without a margin in between). As you can see from the chart, this is only consistently true for the HD 8.9" ('HD9') device, while the HD7 and Android app work correctly with the "comic" booktype value only. In all other cases only one page is shown at a time in landscape mode. Even the Kindle for PC app, which shows an activated two-page button icon, does not actually display two page spreads.

2. Letterbox Color

This refers to the color used to fill in any display space outside the page area, much like the "letterboxing" used in widescreen movies on a 4:3 format television (or iPad). I only tested this because I noticed it was sometimes black and sometimes white and wasn't really paying attention at first to when and where. As it turns out it's only black on the two new HD devices with the "comic" booktype chosen, and white at all other times, with the sole exception of Kindle for PC, where the three standard values of white, sepia, or black are all still available. Not critical, but sometimes one or the other blends better, so it is interesting to know. And given that it is the newest of the Kindle line that sport the black background, this may be an indication of future changes.

3. Virtual Panels

This new feature is apparently a fallback for fixed layout ebooks that have no custom region magnification elements included, and works by dividing the page into four equal quadrants (or "panels") that are zoomed by tapping and advanced in sequential order by swiping (the ordering being based on the "primary-writing-mode" value to allow for right-to-left and left-to-right reading order). Surprisingly, the zoomed page can also then be scrolled around by dragging, and variably resized using pinch-and-zoom, making it a very nice add-on feature for most fixed layout ebooks (in the absence of precisely placed mag zones, that is). As already mentioned, it is supposedly activated by default when the RegionMagnification value is "false," but this value actually has no effect at present: Virtual Panels either work in a particular Kindle reader or their don't, and in most cases they don't. In fact, in only two instances does this currently work: on the HD7 and Kindle for Android app, and only when the booktype is set to "comic." My guess is this feature will continue to roll out until all Kindle iterations have it - aside, perhaps, from the HD9, which somewhat surprisingly doesn't have it; but, then, it doesn't really need it, either, due to its size. However, as you'll see in the next item, you can actually zoom images on the HD9 in certain instances.

4. HTML Image Zoom

This ties in somewhat with the last item, since only one or the other can work. This relates to the HTML <img src="http://feedproxy.google.com/~r/TheAdv... insertion method for adding background images in fixed layout, as opposed to the <div id="...> method of referencing a CSS background-image url. Amazon recommends the latter, but for reasons I will discuss later, I disagree (in fact, Section 4.2.3 of the Guidelines says it's a requirement, because "HTML images interfere with Region Magnification," which is demonstrably untrue). The important factor here, however, is that the <img src="http://feedproxy.google.com/~r/TheAdv... method allows the user to zoom a background image by double-tapping on it anywhere that it's not overlaid by text or Tap Targets, while the CSS method does not. This allows for zooming and scrolling entire background images (minus any text overlays), which until Virtual Panels was the only way this could be done. However, since the Virtual Panels function effectively creates a Tap Target covering the entire page, where that feature is active this one cannot be, since the background image cannot be tapped (the images still appear correctly using the HTML insertion method, so there's no issue where the image's placement is concerned). That said, assuming the RegionMag "true/false" value will eventually work as stated, you will then be able to chose one or the other, so this information will still theoretically be relevant. As seen in the chart, however, it's not just the Virtual Panels factor that determines whether <Img Src> Zoom works or not, since in no case does it work with the "comic" booktype value chosen. But since this is - at present - the only place where Virtual Panels works, in all other case (aside from Kindle for PC) this image zoom method works. An important distinction to make between Virtual Panels and the HTML "img src" method is that that latter only magnifies the actual background image (which is sometimes desirable and sometimes not), while Virtual Panels zooms the entire page, including text overlays, making it more like the iPad's pinch and zoom feature than Kindle's standard Panel View. (For an additional difficulty with Virtual Panels, see number 10. Hyperlinks below.)

5. Cover Image Access

6. HTML Cover Doubling

These two go hand-in-hand, and it all really comes down to one thing: Amazon flat out got it wrong on this one. In Sections 4.2.4 and 4.3.7 of the Kindle Publishing Guidelines Amazon either "requires" or "recommends" (depending on the section) than an HTML page containing the cover image be included in fixed layout files, even though in Section 3.2.3 they unequivocally state that you are not to do this because the cover image may appear twice - which is, in fact, exactly what happens in every instance. They then contradict themselves further by providing (in Section 3.2.3) one exception to this rule, in which case you must enter the linear="no" value to the spine entry for this element (the underlined element being "mandatory"); but then in the later two sections they state that the same value must be set to "yes." All this contradictory information can be cleared away easily by the facts: if an HTML cover is included, the cover image always appears twice. "Cover Image Access" simply refers to whether you can swipe back to the cover once you have moved forward into the book, and was tested in conjunction with the cover doubling issue to see how pervasive the latter was. In only one instance are you not able to return to the cover (even the HTML one) by swiping (or tapping), which is on the HD7. You can still access the cover via the menu link on this device, when again you will be presented with two consecutive covers, one JPEG, one HTML, but you cannot swipe back to it once into the book, whereas on every other device or app you can do so, and there will always be two consecutive cover images in a row. Therefore, there is simply no reason whatsoever to include an HTML cover, and several good reasons not to.

7. TOC Menu Link

Since we're on the subject of menu links, here's another issue to consider. For some unfathomable reason, Amazon has decided to remove the "Table of Contents" link from the default "Go To" menu on the new HD devices. And not only that, but on ebooks with the "children" booktype value the entire "Go To" menu is inexplicably missing. Gone. Completely absent. No links to the cover, the beginning, or any other internal links. Apparently they think readers of children's ebooks don't use menus, nor that comics should ever have a Table of Contents - which, granted, they often don't, but lengthy graphic novels could certainly benefit from one. Perhaps they thought removing it was better than including a Go To menu where all the links are non-functional, but even so, removing the option is a bit reactionary, especially considering that the menu is still present and fully functional in all other Kindle readers.

8. Bookmarks

9. Live Text Functions (inc. Notes, Highlights, Search, & Definitions)

Of all the ebook functions that should never be disabled, these are the ones. If any feature promotes digital reading over print it's the ability to interact in highly useful and informative ways with the text. Being able to annotate, highlight (without ruining the book!), instantly search the entire text, and get the meaning of any word with just a tap of your finger - not to mention adding as many bookmarks as you like - are just some of the wonders that set ebooks apart. And yet Amazon has somehow decided (intentionally or inadvertently) that these features are not needed in children's books or comics. For with either of those booktypes entered they are all disabled - with the single exception of bookmarks in "comics" on the Android app. And mind you, this is not a fixed layout issue, not some odd quirk in the fixed layout Kindle code, since when you delete the booktype value altogether (or enter "none") all this functionality is back, with the fixed layout intact. It did not used to be this way for the "children" booktype, which originally retained live text functions, although "comic" did not have them from the very first. However, disabling them for children's ebooks only happened recently. I have ranted long and often on this here before, so I won't go on at length now. To me, there is simply no justification for this decision, since decision it must be, as there is no logical reason why a manufactured metadata value would have any effect it was not designed to have, unless Amazon is just not paying attention, which I find unlikely.

10. Hyperlinks

Somewhat similar to the live text problem is the issue of interactive links, both internal and external. Here there is fortunately only one disparity, which is on the HD7, where the "comic" booktype completely disables all text hyperlinks, none of which work at all. External hyperlinks are still blue, but non-active. This is clearly related to the Virtual Panels feature, rather than live text functions, since in all but this one instance hyperlinks work correctly even where live text is disabled. But as Virtual Panels currently only work on the HD7 and the Android app, it is possible that this feature is somehow interfering with the links, since Virtual Panels overlay the entire page with a tap target. However, given that the Android app is not effected, it's uncertain what is actually causing this. My concern is that as the Virtual Panels function is rolled out across devices the loss of hyperlinks might become a widespread problem. Hopefully the HD7 issue is an aberration, but it's 50/50 at the moment, so we'll just have to wait and see. Fortunately in most cases this is not an issue at present (which is little comfort to owners of a brand new HD7).

11. Font Embedding

This was just a standard test that I'm happy to report has essentially become unnecessary, as font embedding is now supported by all tested Kindle devices and apps. This was not the case just a few short years ago, when Kindle reflowable files did not allow custom fonts. Now they do, and KF8 has supported them from inception, and happily continues to do so. I include it because it's just good to know. And it's always nice to end on a positive note.

CONCLUSION

These are all considerations each ebook designer must weigh and make decisions on, based on their project and target audience. Bear in mind that digital publishing is still in its infancy, and in a state of great upheaval at the moment. All of this will settle out in time, but for now we have to be aware of what is possible and what is not, and try to stay abreast of any changes (which are numerous and often). Already this chart shows the great disparity between a single year's development of the Kindle Fire line: in at least half the features listed there is a difference in functionality between the 1st generation Fire and the latest models.

My biggest issue continues to be the lack of support for live text when either booktype value is entered, making my clear recommendation not to add one. The only functionality that will be lost by doing this are the two instances where Page Spread works with the comic value entered, but not when it is absent - these being the HD7 and Android app - as well as Virtual Panels on the same two readers. But since these features are hardly universal, being not yet present in any other case (aside from the HD9 where Page Spread is functional regardless of booktype), there is very little incentive to add a booktype value. The primary exception, unfortunately, is that only the "comic" booktype allows images of up to 800kb in size; otherwise, you're restricted to 256kb for fixed layouts, which can be a significant consideration with the advent of HD displays. Of course, this may all change (and probably will) over time as new updates are rolled out. But one cannot plan current work based on future possibilities. One must take what data is available today and use it to inform your present efforts.

As mentioned, I will update this chart regularly, and note the changes made at the bottom of the post. If a large number of changes are suddenly made - say, when a new line of devices arrives - I will do a new post and reevaluate the situation.

And by the way, if anyone has a 2nd generation Fire or a Mac with the Kindle desktop app and can test any of these features I would very much appreciate the information. I would love to add it to the chart for reference and will gladly give you ample credit and provide a link, both here and in the published ebook. For that matter, if any of your own testing contradicts what I have listed here, please let me know so I can look into it further. Comment below or send an email to scot(at)fantasycastlebooks.com.

UPDATE 1/6/2013

Just for the sake of being thorough, I went ahead and tested the eInk Kindle 3 and Paperwhite devices. And while I won't bother to include the data in the chart above due to space restrictions, I will point out the primary data points here.

First, and most surprising, is that the Paperwhite actually supports Page-Spread in all booktypes. This is accessed via the menu's "View in Landscape" option, since the Paperwhite has no internal orientation sensor. Just as interesting is the fact that, while the Kindle 3 does not support Page-Spread, it does default to landscape orientation for the booktype values "children" and "none" (though inexplicably showing only one page at a time), while for comics it reverts to portrait orientation. There is no way to change the orientation from the Kindle 3 menu. Letterbox color is white in each instance.

Equally surprising is support for Virtual Panels on the Paperwhite with "comic" or "none" booktypes (but not for children's books). This is, therefore, the only device that currently does so with the booktype absent, and only the second device that supports it at all. Why the eInk Paperwhite would support this function, but not the 1st gen Fire is beyond me (except that the Fire's OS has not been updated for some time).

Another curious fact is that pinch and zoom is available for all pages on the Paperwhite with any booktype setting, regardless of image insertion method. The Kindle 3 has some default zoom functions available via the menu, with incremental 5-way controller scrolling in all directions rather than the Virtual Panels' default quarter page progression. So that's a sort of "qualified" yes for that feature.

Cover issues remain consistent on both devices, and there are no Table of Contents menus in any instance. Bookmarks are functional in all three booktypes on the Paperwhite, but not at all on the Kindle 3, even though it retains the default Bookmark and TOC menu links, they're just grayed out and inactive. There are no live text functions, nor active hyperlinks, on either device in any booktype, but font embedding is consistently present.

UPDATE 1/15/2013

The chart has been updated to incorporate the tests I ran on the Kindle eInk devices for ease of reference and comparison. This makes the text in the table somewhat smaller that I'd like, but this is a restriction of the blog format. You can easily use the zoom function on your monitor to increase the text size for better readability, or - since it's a live table and not an embedded image - copy and paste it into a word processor and increase the font size.

UPDATE 2/18/2013

Removed information regarding Guide items, which now receives a more in-depth analysis within the body of the tutorial.

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on February 18, 2013 12:02

February 14, 2013

Kindle Fixed Layout Tutorial - Part 7



This section can be just a few short lines giving only the bare essentials of title, language, and identifier (the only three that are required), or add a host of other information that can be useful for identifying and indexing your title. In this, more is always better, as individual systems can ignore non-relevant portions, but cannot make them up if they are not provided. Furthermore, much of this information is searchable in online catalogs, such as Amazon's search engine and the Google Play bookstore, helping potential readers find your work.

There are 15 elements, known as "properties," in the standard Dublin Core Metadata Element Set (DCMES). These are (in alphabetical order):

Contributor

Coverage

Creator

Date

Description

Format

Identifier

Language

Publisher

Relation

Rights

Source

Subject

Title

Type

Not all of these are relevant to all ebooks, nor were they created specifically for ebooks, but rather for electronic publications in general. The purpose of using a standard reference set such as Dublin Core is so that everyone who might reference or add to the data pool will be using a common vocabulary.

To see the official documentation, visit the Dublin Core Metadata Initiative. For the IDPF's ePub 2.0 specification set, see Section 2.2: Publication Metadata.

I will describe each property - grouped into a more or less logical order - along with their modifiers and options, but you can also find a complete table of all fifteen in Appendix C of the ebook tutorial, along with concise descriptors and reference links (included at the end of this post).

<title>

The <dc:title> attribute is one of three required elements in any ePub-based ebook, Kindle included. This is the title that will appear on the Home screen or Kindle Bookshelf in list view. You can add more than one, using separate entries, either for subtitles or series/volume titles. But the primary title by which you want your ebook to be listed must be given first. Simply insert the title of your ebook between the angle brackets, like so:

<dc:title>YOUR TITLE HERE</dc:title>

There is no opf modifier to designate a given title entry as the series title or a subtitle, so the order in which they are listed is critical. You can enter it all as a single title, or as separate entities, but whatever is in the first entry will be how the book is listed anywhere that it appears.

You will also be allowed to enter additional title information during the upload process to KDP, including Series titles and/or Volume numbers. But be sure to include it in the metadata section, so that no matter where the ebook goes, the information will go with it. For example, it may be sold to libraries or academic institutions, or find its way to secondary resellers if used ebooks become a legitimate market in the future. And, of course, you want it to appear correctly in the reader's own device library.

As a side note, you should be aware that ebooks will only appear on the Books tab of the Kindle device after they are downloaded from Amazon. Otherwise, they are considered personal documents and will appears on the Docs tab, even when you put them in the Books folder on your device. This is unfortunate for those who wish to sell ebooks directly to their readers, but you cannot change it, so don't try. A metadata entry called "CDE Type" with the content value EBOK (or EBSP for samples) will be created during the KDP upload process, but it is ignored if added manually. Incidentally, Calibre will add the EBOK entry during its conversion of reflowable ebooks, but unfortunately it cannot yet convert fixed layout files correctly.

<creator> <contributor>

You are required to include a title, for obvious reasons, but not an author or other creator, as works can be anonymous. There can, of course, also be multiple creators of a work, and each of these should be entered as a separate entity. The OPF spec adds two optional attributes to the <dc:creator> element that greatly aid with this and extend its value as a data attribute. The first of these is file-as, which allows you to specify the last-name, first-name sorting order for creator names, as in:

<dc:creator opf:file-as="Last, First">First Last</dc:creator>

If you leave this out your ebook will be listed under your first name in many catalogs and databases, such as the Calibre library.

The second opf modifier is the role attribute, which has a wide range of values to specify the exact function of each creator or contributor to the work, including author, illustrator, editor, and many others. In addition, there can be multiple entries of each.

These are entered using a three-character code, such as "aut" for author or "ill" for illustrator, as seen in the template metadata. For a complete list of the 223 role values and their 3-character codes, along with a description of each role's function, see the MARC Code List for Relators.

<dc:creator opf:role="aut">Your Name</dc:creator>

In the unlikely event this extensive list does not contain a value for a particular function utilized in the production of your work (the required skills for creating ebooks are expanding rapidly, after all), you can add generic contributor elements using the "oth" value for any others whose roles remain unspecified.

All role values can be used for both the creator and contributor elements, each of which are entered in the same way. The distinction between these is that creators are the primary producers of the work, such as the author or an artist of a heavily illustrated children's book or comic, while translators or designers who contribute to the work should be listed using the <dc:contributor> element. In many instances this might be a purely arbitrary distinction, but in general those who produce the work are creators, and those who help to shape the work are contributors. But there is no hard and fast rule for usage, so use your best judgment.

<publisher>

The publisher of a work is defined as the entity responsible for making the publication available in its present form. This is somewhat less obvious than one might think for self-published books, for the simple reason that the legal "publisher of record" is the entity to whom the assigned ISBN is registered, and not necessarily the person or organization on whose book it ends up.

For example, if you publish your ebook through Smashwords, they will provide you with a free ISBN. However, contrary to popular belief, you will not be a "self-published" author, since the publisher will be listed as Smashwords at every retail vendor who carries your ebook. This is a technicality for all intents and purposes, since you will have "self-published" your own work. But you are not the publisher, Smashwords is.

Conversely, if you do not provide an ISBN when uploading your ebook to Amazon (or Barnes & Noble or Google Play, who do not require one), they will assign their own "unique identifier" to your work (an ASIN in the case of Amazon), but you will still be listed as the publisher.

This might seem a fine idea from a financial standpoint, since ISBNs do not come cheap (at least in the United States: in Canada they're free). However, this makes cross-referencing your works vastly more difficult for archivists and collectors, not to mention librarians who might want to buy your ebook. With an ISBN assigned to the ebook edition of your book (it cannot be the same one used for a print edition, if there is one), your title can easily be found anywhere that it is listed. In addition, all sales for that title will be aggregated in bestseller lists, whereas this is not always the case for titles with a different number assigned at every vendor.

The sole reason I point this out here is that simply entering your personal or business name into the publisher metadata entity does not make you the publisher of record - legally, at least, which may become an issue down the line if you decide to sell your Smashwords published ebook to another publisher. It is always best to have an ISBN assigned to your work, and for legal reasons it is always best to have it registered to you.

<date>

The opf spec adds the event attribute to the <dc:date> element, allowing you to specify the nature of a given point in time, such as the date of creation, publication, modification or revision, of which you can include one, all, or none. There is no defined set of date values, so you can enter any that you feel might be useful, such as an entire revision history, or just the date that it was finished. Only the first one will be recognized by Kindlegen during conversion, but the rest will be retained in the internal metadata.

<dc:date opf:event="publication">2013</dc:date>

The date element is optional (though recommended by Amazon), and if used you can enter just the four-digit year as shown and call it good for most books. However, if you're working on a periodical or other timely content (or simply like to be precise), you may want to include the month and day as well. If so, you must use the year-month-day format of YYYY-MM-DD in order to conform to ePub standards.

<rights>

A statement of your rights within the metadata is recommended, though not required. This can be anything from a simple "All Rights Reserved" (or creative commons, public domain, or whatnot), to a full assertion of your Intellectual Property Rights in different territories and/or under various conditions (as, for example if you're doing translations into different languages, or have retained the ebook rights but not the print edition rights). In most cases, if you're getting this involved you'll want to consult a literary agent or legal representative who knows publishing law.

A reference to the system of protection should be included along with any assertion of rights, such as "Copyright" or "Trademark" for print and graphic elements. Thus, a standard concise statement of universal rights might be:

<dc:rights>© Copyright YYYY - All Rights Reserved</dc:rights>

Within the XML code framework of the OPF file you should include the full word "Copyright," and/or use a universally recognized string to stand in for the © symbol, as it may not be recognized by reading systems throughout the world. Three standard, code-based alternatives are given here:

Character

Decimal

Hexadecimal

Named Entity

©

©

©

©

<language>

The second required element is at least one entity that identifies the primary language of the content. This should employ the standard RFC 3066 Unicode language identifiers, using a base two-letter code, either alone or with a secondary string, or "subtag" for a language variant. So, for example, English can be either plain EN, or EN-US for United States dialects, or EN-GB for British idioms, or any of a host of others. Values are not case-sensitive, so en, En, and EN are all valid entries.

<dc:language>En-US</dc:language>

Generally it is best to avoid using subtags unless it is clearly relevant to the work, as it inherently alienates speakers of related languages for which the work is equally accessible. On the other hand, readers might be interested to know that they are in for British slang when diving into Harry Potter for the first time.

You can also include more than one language identifier if more than one language is used in the work, as are found in dual-language translations, or where large portions are given in another tongue, such as Latin passages in a history text. It is not necessary to include a language identifier for single foreign terms scattered throughout a book, unless it is required to know the language for comprehension of the content, or where are a large number of foreign terms have been inserted.

<identifiers>

The third and final element you are required to include is at least one unique identifier. As mentioned in the introduction to the OPF file earlier, there must be one identifier with an id value that matches the value of the unique-identifier element in the header declaration, and this is where it goes.

An identifier is a reference to the publication from a given system of documentation, the most common of which is the International Standard Book Number (ISBN). However, it can be any string of data that is specific to this particular incarnation of your work, though preferably one drawn from a formal identification system, such as a Globally Unique Identifier (GUID), Uniform Resource Identifier (URI), or Digital Object Identifier (DOI). No particular identifier schema is required, nor has any been endorsed by either Dublin Core or the IDPF, although, of course, an ISBN is universally recognized as the standard for publications.

Multiple identifiers can be used instead of, or in addition to, an ISBN, but as mentioned, one must be the globally unique identifier. This is specified by an XML id tag that matches the unique-identifier value in the header. The value itself can be any descriptive term or key phrase, such as the common "BookId" or "book-id" employed both by Amazon and Apple in their samples. The value is case sensitive only in that its two entries must match exactly. Otherwise the id value is essentially arbitrary, functioning merely as a label for the data string, although, of course, you will want it to make sense and clearly describe the contents of this particular identifier.

In addition to the id value, the OPF spec adds an optional scheme attribute that allows you to name the specific system of authority that generated or assigned the data used as the identifier. Here is where you would enter "ISBN" or "DOI", or whatever the source of the data string may be. Here again, the OPF spec does not endorse or restrict you to any given identifier scheme.

In the templates I have included three identifiers, each with a particular function. The first of these is labeled "BookId" and is used to identify the Version number of the ebook, since there is no other means of doing so within the metadata, aside from a "revision" event in a date element. It is good practice to include a version or edition number on the copyright page within the ebook itself for the reader's reference, but in order for electronic databases to recognize a revised edition, you will need to include it in the metadata.

The second line in the template is given only as an example of how to enter an ISBN, since the template itself does not have one, being free. You would simply enter your ISBN number between the angle brackets, where it now says NONE. The id that I've entered for it here is just an arbitrary label, and has no actual value. But I could make this the unique identifier simply by changing either the id value here or in the header so that they match.

The final entry is the one I have used as the template's globally unique identifier, and as you can see it matches the unique-identifier value in the header declaration.

Here I've used a standard 32-character data string known as a UUID, or Universally Unique Identifier, which contains an encoded timestamp based on the moment and node location where it was created. These can be generated at no cost on many websites, including UUIDGEN, where one is automatically created the moment to land on the page. The string itself is the portion after the prefixed urn:uuid: tag. The "urn" element stands for Uniform Resource Name, which is a predecessor of the URI and URL.

The dtb:uid value of the id will be found in the metadata section of the NCX file as well, where it should match this data string as well (if used), although it is not strictly necessary. I'll discuss that further when we get there.

The UUID is particularly useful in that it can be decoded to discover the exactly moment and location of creation, but looks like utter gibberish otherwise. Each time you update the ebook's content, however trivial, you should alter this data string, as well as the version number if used, in order to allow users (or yourself) to identify the particular version they are holding.

<type> <subject>

By using the type element you can add category data such as whether the work is Fiction, Non-Fiction, Poetry, etc., and/or a specific genre or classification, such as Science Fiction or Art History. You can also include functional descriptors for such works as Almanacs and Working Papers. The values here are limitless, but should use commonly recognized terminology.

The subject element, on the other hand, is used to define the topic or subject matter of the content itself. This is where you would add Library of Congress classification codes, BISAC Subject Headings, or others such as those used by Amazon to categorize their entries (many of which will be drawn from these metadata entries). One reason you're adding all this extra information is precisely so that retailers can add it to their product pages. Adding it here facilitates the quick and accurate transfer of metadata concerning your work, and this is your chance to make sure it's right.

The template provides half a dozen examples of subject headings that might be appropriate for such a work, drawn from the BISAC listing. You can add as many as you like, and as always, more is generally better than too few.

<description>

This is where you place the back jacket blurb or other descriptive content that tells the reader what the book is about, with the intention of enticing them to read it. Anything you might desire a potential customer to know could go here, including reviews, extracts, or a table of contents to let them know exactly what's included.

Aside from the content of the book itself, this is the most important piece of writing you will do with regard to your published work. Give it some serious thought and apply your finest craftsmanship, as it will show up all over the Internet, on every ebook retailer and social reading site, as well as book review blogs and library lending catalogs, and once it's there it's there for good.

<format>

One other tag you might include is format (Kindle in this case, but ePub or iBooks or whatever is appropriate otherwise). This might seem redundant since you've got the ebook right there in front of you, but not everyone reading this data will, and it's one more way this specific iteration of your work can be identified. For example, a library may be looking at a metadata listing in search of a particular format to include in their catalog, and other general ebook retailers will want to identify the format for their customers before selling it to them via whatever systems are put in place down the line as ebooks become more common.

There are a handful of other elements that you can add in order to expand upon or define further aspects of your work, such as its sources or relation to other works. Following is the Appendix C table containing the complete list and their definitions.

Before moving on to the next section of the OPF, be sure to close the metadata section by using the backslash </metadata> tag. It's also a good idea to check through your list of entries to be sure that they're all closed as well.

DUBLIN CORE 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 4-digit 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 or URI. 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 specified.

language

Required. One or more language identifiers, with optional region subtag, such as en-us for English as spoken in the United States, 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.

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on February 14, 2013 21:32

February 9, 2013

Kindle Fixed Layout Tutorial - Part 6



The first group of attributes in the metadata section are those that pertain specifically to Kindle fixed layout ebooks (see end of post for a complete list), and the first of these is the one that makes the layout fixed:

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

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

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

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

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

Next up is the orientation function:

<meta name="orientation-lock"

content="portrait/landscape/none"/>

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

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

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

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

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

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

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

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

horizontal-lr

horizontal-rl

vertical-lr

vertical-rl

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

<meta name="zero-gutter">

<meta name="zero-margin">

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

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

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

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

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

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

Table of Kindle-Specific Metadata Attributes

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on February 09, 2013 16:05

February 5, 2013

Kindle Fixed Layout Tutorial - Part 5

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 and often throughout the creation
process.

OPF stands for open
packaging format, which refers to the 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.
It also provides some crucial information specifying how the Kindle will
display your pages.

This is the first of many files where we will need to explain
some things to the computer so it understands what we're saying and what to do
with the information that we give it.

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 code is based on ePub 2.0, the standard laid out by the IDPF (the
International Digital Publishing Forum), which is what this declaration
specifies. You will find similar instances in the NCX and at the top of every
HTML file.

The only part you need to be aware of here is the very last
element, which is a "unique-identifier" that will be referenced in
the metadata section below, where it will be discussed further.

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 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 independent bookstore or the Library of
Congress (or Copenhagen, or wherever it may wander in this worldwide market),
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 metadata, 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. These function for the
most part 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
declare our data reference systems, of which we'll be using two. These you will
find on the first line of the metadata section:

<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.

The general practice is to state the dc element followed by
an opf extension (if desired), such as this example for an ISBN:

<dc:identifier
opf:scheme="ISBN">ISBN#</dc:identifier>

where the generic Dublin Core identifier
is defined by the opf:scheme modifier
as an ISBN. The actual data is entered between the angle brackets: here as ISBN#, which you would, of course
replace with your own information, as will be the case for each metadata entry
in the general metadata section (Amazon's Kindle-specific system is slightly
different).

Technically, no opf modifiers are required, but their use
provides considerably more information, as you can see. And while not all
ebooks will include both, I have included them here for your reference, so that
you can use them if you choose.



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 can consequently be deleted or altered
at your discretion. It is used to pass along useful notes or help to organize
the content. Here I have used it to create sections and sub-sections, and to
point out important elements. In css files forward slashes and asterisks are
used instead, like so:

/* comment */

There the text also turns green, which is even
more helpful. But here in the opf everything is black and white.

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on February 05, 2013 20:39

February 2, 2013

Kindle Fixed Layout Tutorial - Part 4

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.

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 those as well (the 7-part tutorial on this blog shows you how). With some minor modifications, the same file can be re-configured to meet ePub and iBooks specs, making it readable on virtually any device. If you have already read my iBooks tutorial then you will recognize much of what is included in a Kindle ebook file, and you may also notice that a few items are 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 many cases, you can simply leave the Kindle code intact and add the iBooks code in too! Here, however, we are focusing entirely on Kindle fixed layout ebooks, which can only be read by Kindle apps and tablets.

Opening the File

If you haven't downloaded one (or both) of the free 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 download the .epub version of the template so that you can open it. 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, by either 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 options to open it with your zip tool of choice.

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.

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 choose one), rather than as a collection of files contained within a zipped archive. The .epub file will open as an ebook, by the way, but it will not display correctly, since it is a Kindle file that has not yet been converted to Kindle format. Kindle apps and devices cannot read ePubs, and so this will not be one of your choices for opening the file as an ebook.

Inside the Template

When you look inside the template (or at the contents that have been extracted) what you'll see is two files and a number of folders (three in the simple template and four in the advanced version), which look like this:

content.opf

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 in 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 that you do, 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 to the folder's name. We will look at each of these in turn.

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 size images, each one much be contained in a separate html file with precisely defined dimensions.

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 see that there are no mimetype or container.xml files, and no /META-INF/ folder included here, such as are required by other ePubs, including iBooks. While these must be manually created for other fixed layout formats, the Kindle conversion process creates them for you automatically. So there are two pieces already that you don't even need to know!

A Note On File Names: With one exception, the names of the files 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.

Other than this, you're free to name your files however 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 boatload 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 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.

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on February 02, 2013 22:57

January 31, 2013

Kindle Fixed Layout Tutorial - Part 3

TOOLS

A NOTE ON THE TEMPLATES:

The companion templates are provided both in their final Kindle format as well as in epub format, the current standard
on which all ebooks are based (with many proprietary modifications by Amazon, Apple, and Barnes & Noble), and which will form the basis of the file you
will build before converting it to the final compiled mobi format for upload to Amazon or your own device.
Kindle files cannot be built directly, but must be converted from a
"source" file; nor can they be opened for editing directly, but must first
be extracted and converted back to epub. In addition, 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 version of the templates will allow you to view the
source code referenced in this tutorial, and to replace the template's contents with
your own. This tutorial provides step-by-step instructions on how to do just that.

In addition to the template, a number of additional resources will either be required, or come in handy as you set to work creating your masterpiece.

I. CONTENT EDITING

1. Text Editor

Even if your book consists entirely of images, you will still need a good text editor capable of creating clean, plain text files (i.e. not rich 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 complex files. 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. A good web building program such as Dreamweaver is almost overkill for building ebooks, but will certainly do the job. For reasons to be mentioned shortly, I prefer a program that opens quickly, unlike the slower loading Adobe software.

A Note on InDesign: Adobe's premiere layout software will export to epub, but it also inserts a lot of extraneous code into the files that make it more complex than necessary to edit, requiring a lot of "clean-up" that is often more work than creating a file from scratch. This tutorial will not attempt to explain everything you'll need to remove from your epub file in such cases, but only what you need to put into it. Once you've learned that, you'll be more readily able to clean up an InDesign exported epub.

Additionally, Amazon offers an InDesign plug-in for export directly to Mobi, but this does not yet fully support fixed-layout features such as region zoom. Consequently, I do not cover InDesign exports in this tutorial. However, the files produced can be edited using the instructions contained here.

2. Image Editor

Images in Kindle ebooks need be correctly formatted both for pixel resolution as well as file size. Thus, you will need an image editor like Photoshop or the 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 tutorial.

3. File Compressor / De-Compressor

An epub file is really just a zip package with its extension changed. You can manually change the .epub extension to .zip in order to extract the files inside and add new ones (be sure to change your file browser settings to show extensions so that you can edit them). However, some programs, such as 7-Zip, allow you to modify the contents of an epub without changing the extension, or even extracting the files, which can save you a great deal of time. Set your preferred text editor (i.e. Notepad++) as the default in 7-Zip (Tools > Options > Editor) 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. You can also drag and drop new files into the archive, or delete ones that are already in there.

II. CONVERSION TOOLS

1. Kindlegen

As mentioned, Amazon provides a free conversion tool called Kindlegen that can produce a final Kindle compliant file that can be uploaded to KDP or distributed to Kindle customers as you see fit. This is a command line tool that is simple to use, accepts epub input (as well as X/HTML), and supports all the features of KF8. Although it may appear complex at first, 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, both for ebook conversion and organizing your digital library, it does not fully support fixed layout formats, due to their complexity and the proprietary nature of some included code, which will not work in other formats. Do not attempt to use it to produce fixed layout ebooks in Kindle format.

2. Kindle Previewer

Another free tool offered by Amazon is this graphical interface, intended (as the name suggests) for previewing your Kindle file before uploading to KDP. However, it also functions as an interface with Kindlegen, automatically converting epub inputs into Kindle format for previewing. Consequently, some prefer to use it for this purpose rather that accessing Kindlegen directly.

Kindle 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 display on any given Kindle reader. Since few authors can afford to purchase every device available, this can be quite useful. Unfortunately, the previewer has been plagued with bugs and is notorious for not displaying content accurately. It's better than not having any idea at all, but I 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.

III. THIRD-PARTY UTILITIES

1. Mobi Unpack

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 Mobi Unpack will be 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. This is not required for this tutorial, but its use and purpose will be discussed here to some degree,
along with a few of the more interesting results you may find.

2. KindleStrip

The file created by Kindlegen will always be much larger than the source files from which it was created. This is because the final 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 fixed layouts. In addition, the original source files are also included in the final .mobi package as a zipped archive, just in case Amazon needs them for re-converting later. However, only the portion relevant to a customer's device will be downloaded from Amazon to their e-reader, so the actual file size delivered will be smaller than the one created. You may want to "strip" the file in this manner yourself for selling elsewhere, such as on your own website, or through other retailers. KindleStrip is another python script that fulfills this function.

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.

IV. DOCUMENTATION

1. 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. Sadly, there is both a wealth and
scarcity of useful data, in unequal measure, some of which is contradictory and some just poorly
written, none of which is thorough, although much is critical to know. You'll
get the necessary portions here, but I recommend you also read the official
guidelines when you find the time. They will make more sense once you have worked through this tutorial.

2. 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. At
present, however, they are somewhat out of date, although they have occasionally been updated. 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.

3. 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 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 - An Amazon page that lists the major elements supported
in KF8. Though not exhaustive, these are more than most authors will ever need.
The list is also included as an Appendix in the Kindle Publishing Guidelines.

International Digital
Publishing Forum (IDPF) - Central hub of the committee tasked with
developing and maintaining the ePub spec, on which all major ebook formats are
based, including KF8. Because of this it is useful to know the actual code and
its parameters.

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.

A number of other specific resources will be mentioned at the points where they are
relevant.

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on January 31, 2013 20:17

January 30, 2013

New "Tutorials" Tab

To make gleaning information from this site a little easier for those who are searching for the various tutorial posts and related ephemera that are now scattered about this blog, I've created another new tab up on the menu bar, this one appropriately titled "Tutorials". There you will find links to each part of the iBooks and Kindle fixed layout series, along with the earlier KF8 image zoom tutorials.

In addition, I have added a link to the iBook Template on the "Templates" tab, as well as some additional links to further discussions of KF8 fixed layout functionality posted in the several updates made to the original KF8 Template, under which they can now be found. I will continue to update these tabs as new content is added.

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on January 30, 2013 19:51

January 29, 2013

Kindle Fixed Layout Template - Advanced Version

Here at last is the complete, 18-page advanced template for creating ebooks in Kindle fixed layout format. Unlike the simple, image-only edition of the template, this one functions both as a template as well as an extended sample of what a Kindle fixed layout ebook can do, demonstrating with progressively more complex examples just what each function does. Each page is designed to illustrate a single feature of the code (though sometimes more), with each one building on what came before. Thus, any given page can provide the code required for your particular project; or you can take all the portions that appeal to you and build your own fixed layout ebook using that as the starting point.

Within the various component files (html, css, opf) are contained some interlinear notes listing the various sections of code and pointing out the relevant portions for that page. These are neither exhaustive nor explanatory, as the companion tutorials will provide the detailed commentary and analysis, but they serve to organize and clarify the use and structure of the code for ease of reference. Incidentally, I have employed a number of variant ways to reference the CSS, which I will discuss at the proper time, but be aware that this is not a lesson in HTML or CSS, and those elements are only explained insofar as they relate to creating Kindle fixed layout ebooks specifically.

As with the image-only template, this one is available for free download on the "Templates" tab above, both in a compiled .mobi file format for viewing on your Kindle, as well as the .epub source file from which it was created, thus allowing you to crack it open and tear it apart to your heart's content.

Bear in mind that all text and image content is my own and cannot be sold or used for any commercial purposes whatsoever, and are only included to provide examples of KF8 code usage. The template itself is offered under a Creative Commons license and can be distributed freely so long as no fees of any kind are involved. Any work derived from it is strictly your own, provided the above stipulations are met.

Here is a rough breakdown of what is included in the template:

Image-only page, using self-contained CSS within the HTML file
Text-only pages, with or without background images
Thumbnail image expandable to full-page size
Table of Contents with active links and custom styling
CSS <div id=> versus HTML <img src=> image insertion methods
PageId Spine attribute: "page-spread" versus "facing-page"
Embedded text versus "live" text
MagZoom using "sourceId" for magnifying default text content, with or without additional styling
Alternate text placement examples using magTarget values to move zoomed content
Adding backgrounds to magnified regions, using images or Lightbox fills
Emulating word wrap around images using precise line positioning, as well as word and letter spacing
MagZoom using "TargetId" for creating magTargets with alternate content
Alternate formatting for magnified text, with either the same or different content
Image switching by inserting different images into the magnified window overlay
Region Magnification using Panel View to zoom specific sections of an image
Using temporary color fills to position panel MagRegions
Lightbox effects for dimming the surrounding background
Using TargetParent to create a Lightbox fill within a text box
Switching the entire contents of a page with one action, including images, live text, and an active hyperlink in the activated content

With the advanced template now completed, the blog portion of the tutorials will recommence on a semi-regular schedule, while the companion ebook edition should appear within a fortnight - barring unforeseen interruptions, and depending on the speed of final proofreading and corrections. Given my tendency toward methodical production, expect it to be more like a month (and then double that for good measure). But the online tutorials will continue presently.

Finally, please do not inundate me with questions about how to do things demonstrated in the template, as these will be answered in due time as the tutorial progresses. Be patient and bear with me, as I have a full time day job, am attempting to produce a 300+ page graphic novel, and have a course load of over 400 hours of video instruction to wade through in the next few months. Feel free to leave comments and questions regarding content already discussed here that you'd like more information on, but I won't respond to anything I plan to deal with in a future post or in the forthcoming ebook.

Best of luck with your own projects, and let me know how it goes. I'd love to see what you come up with!

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on January 29, 2013 21:16

Page Turn Prototype Demo Video

This is the coolest thing ever! I want this on every e-reader I own!!! Why would you not want this? And why is it not already available? Seriously, if this does not start to show up on next year's ebook apps and devices then I will be sorely disappointed. I would use this all the time, for reference works I read or glancing back at a map or list of characters to refresh my ailing memory.

Setting aside any commentary or arguments for or against replicating the physical book experience in the digital medium, it can be hardly be debated that for any linear string of a text or data to be presented at its best it requires the most flexible system of accessibility possible, since one can never know exactly how the end user might want to interact with it. And since not all ebooks are alike, no one method of approaching them will suffice for all. It's good to know that someone out there is thinking seriously about these things. I just hope that Apple and Amazon (and Google and Samsung...) are paying attention.

View more on R. Scot Johns's website »

Like • 0 comments • flag

Published on January 29, 2013 15:59

← Previous 1 2 3 4 5 6 7 8 9 10 11 12 … 25 26 Next →

R. Scot Johns's Blog

R. Scot Johns's profile
11 followers