Saturday, July 11, 2015

Kindle Publishing Guidelines 2015.2

Just a few quick notes on this latest update to the Kindle Publishing Guidelines. Most of it covers minor details, but there are a couple of interesting items. All the sections containing changes are listed in the Revision History shown above (highlights mine). Those three highlighted sections are all deletions relating to Adobe products, and along with the removal of InDesign from the list of means by which "publishers can create Kindle books in-house...using Kindle Publisher tools" in Section 2.2, expunges all prior references to Adobe in the Guidelines, save for one mention of InDesign in Section 2.3 Third-Party Conversion Services, where it's listed as a "typical input format" for outside conversions (i.e. non-Amazon related).

2.2.1 Kindle Plugin for Adobe InDesign

The deletion of this section removes any mention of the Kindle Plugin for InDesign in theGuidelines, along with the link to its web page. That page still exists, and is linked to from the side menu of the other Kindle Publishing Tools pages, but is still marked as "Beta." The removal of it here from the section on "Paths to Getting Your Content on Kindle" implies that Amazon are giving up on support for this plugin, and no longer consider it a valid path to publication.

This is not wholly surprising, given that they haven't updated the plugin (or the corresponding Kindle Plugin for Adobe InDesign Publishing Guidelines) since version 0.973 in September of 2013. In fact, they've never updated the plugin for InDesign CC, and still list CS6 as the latest version supported. But then, they still list Windows 7 as the newest PC operating system too. Until now I just presumed they were being negligent, but the intentional removal of this section says otherwise. Were they preparing to release an update they would not have done this. Using KindleGen

Removed the "C:>" root element from the command line example.

Added a note that "zip formats are supported for XMDF and FB2 sources" and "directory formats are supported for XMDF sources."

Changed/added the following -locale element references:

zh: Chinese (from ch:Chinese)
pt: Portuguese (from bp: Brazilian Portuguese)
ru: Russian (added)
3.1.1 Text Guideline #1: Body Text Must Use Defaults

A new paragraph has been inserted to the third bullet item (detailing the range of gray-scale colors acceptable for text elements with a forced color), giving specific directions on how to determine what the gray value is for a given color. See the Guidelines for details.

3.1.4 Text Guideline #4: Other Encodings Are Supported 

Some editorial clarification here simplifies a previously convoluted and unnecessarily redundant sentence structure, while a second method for specifying HTML encoding by an XML declaration has been added:

<?xml version="1.0" encoding="UTF-8"?>
In addition, the first method (using the <meta> tag in the head element) has had its character set reference altered from the previous "iso-8859-1" to the more standard "UTF-8".

3.1.5 Text Guideline #5: Use Supported Characters and Spaces

Previously titled "Spaces and Unicode Characters," this section adds two new paragraphs stating that plain text UTF-8 should be used to represent characters (hence the change in the preceding section), except where XML entities are required. The second paragraph specifies the three instances where XML entities are strictly required, these being:

< (&lt;)> (&gt;)& (&amp;)
where the values in parentheses are required in order to avoid misinterpretation of the code by the reading system. For example, if ampersands are used in the opf metadata it will result in a failed conversion.

The example is provided here that the © symbol should be used rather than the &copy; named reference.

3.6.5 Image Guideline #5: Use GIF or PNG for Line-Art and Text

Removed the previous reference to the 127 kb image file size restriction. Now it just says " the image size limit."

3.7.3 Table Guideline #3: Create Simple HTML Tables

Removed all the references to specific Kindle iterations, including the Kindle 1 with its particular issue in dealing with tables. Now it just says that <table> tags "can be displayed on Kindle devices and applications." Period. Not sure if this means the ancient K1 can now handle simple tables, or that they no longer care. The only person I knew who had one got rid of it years ago.

3.8.3 Styling Guideline #3: Design for a Good eBook Experience

A new section that adds a lengthy paragraph that is essentially useless, and includes this utterly unenforceable guideline:

Using fixed-layout format just to replicate print layout is not allowed in Kindle books because customers report this as a bad user experience.
As if they could know what your intention was. Maybe you intended to replicate the print experience, results be damned. Or maybe you just suck at formatting. Hard to say. But I guess Amazon intends to try. Does this mean they plan to start pulling poorly formatting fixed layouts? One can only hope. On that note, however, see the next section.

4.1 Metadata Fields Supporting Fixed-Layout Books

Okay, so now we come to the crux of the matter. Amazon has made a crucial change to the Region Magnification metadata description which, oddly, not only does not remove it (even though it's non-functional, and thus, irrelevant), but essentially makes it mandatory. Not the element itself, mind you, but Region Magnification itself. Here is how it now describes this element:

An optional tag for enabling the Kindle Panel View and Kindle Text Pop-Up features that are required for comics and children's books (italics mine).
I employ the italics to point out the seeming discrepancy in the statement. In essence, the tag itself is option only because it doesn't work; i.e. it makes no difference if you add it or what value to assign to it. As I have discussed both in my Kindle tutorial series and my formatting manual, KindleGen will add the RegionMagnification entity itself (and the correct value of true) if Region Mag is, in fact, present in the publication, regardless of whether you put it in the metadata or not, and will remove it otherwise, even if you enter it with a value of false. Thus, there is no point in adding it at all. The tag is truly optional.

However, according to the latter half of this statement - which is the portion added in this update - Panel View and Text Pop-Ups are now required for Kindle comics and children's books (respectively, one must presume, since Panel View is only available in comics). This is not a critical distinction for comics, however, since the Virtual Panels feature is present by default where custom panels are not provided by the content creator. Still, this statement technically makes is a requirement to include your own "Region Magnification" elements, a term the Guidelines uses interchangeably for Panel View (i.e. in the heading for section 5.4).

The real dilemma here, though, is with regard to children's books. Many Kindle ebooks of both types consist of full page images with the text included in the image. This is a poor design decision, as I have often stated, due to the loss of many crucial features, but one that is unavoidable for many ebook creators due to the cost and complexity of adding pop-up elements. According to this new addition, that is no longer an option.

Now, granted, this has technically been the case all along. Section 4.2.2 which follows this has always listed as "Requirement #2" the use of Region Magnification in children's books, rather than adding it to the later "Recommendations" section. But it has not been strongly enforced.

Does the addition of this clause imply that Amazon intends to begin enforcing this rule more diligently, and start refusing children's books with no Text Pop-Ups? Or is it just a strongly suggestive guideline that has been added in order to be more consistent with the section that follows?

Curiously, where this metadata element chart is repeated in Section 5.1 for comics the change has not been carried over. Editorial oversight or intentional omission?

8.1 Media Query Guidelines (and subsections 8.1.1—8.1.5)

Incidentally, I did not do a post when the 2015.1 version of the Guidelinse was released, as it included only this one change, although it was quite useful. This new "Media Query Guidelines" section was added which is fairly extensive and contains a lot of very helpful notes for handling backwards compatibility. This is, of course, primarily of use for reflowing ebooks, and so not as much of interest for my purposes, as fixed layouts are another beast entirely.