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 the Guidelines, 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.

2.2.1.3 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 "...fit 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.

Monday, June 15, 2015

Amazon Changes Kindle Unlimited Payout Method

Amazon has just announced a critically important change to the way authors are paid for titles borrowed through both the Kindle Unlimited and Kindle Online Lending Library programs. The former is Amazon's successful $9.99/month ebook subscription service, while the latter is the one-book-per-month benefit Prime subscription members receive, but both reward the authors of the borrowed books with royalties paid on a monthly basis.

In either case, the authors of the borrowed titles have previously been paid a percentage of a "global" fund each month, divided equally between the total number of titles borrowed, regardless of their length, or whether those books were ever read. This is a crucially important distinction, as it has given and enormous financial advantage to authors of shorter works, since the payout has always been the same for, say, a 20-page children's ebook as it is for a 600-page historical novel: they each count as one borrow, and thus impart the same payment.

This, along with the general downward push of ebook pricing by consumers who feel ebooks should be cheap due to their lack of physical substance (as if the content does not matter), has lent great emphasis to the proliferation of shorter works which can be produced (and consumed) much faster. The continuing trend of children's ebooks to top the sales charts in percent of growth year-on-year bears witness to this trend. And while I am not an advocate of exclusivity in general, there has been very little incentive for authors of longer works to enroll their titles in Kindle Select, Amazon's exclusive distribution program that is required for all titles to be included in the lending programs.

However, today Amazon announced that beginning on July 1st, they will radically change the way that payouts are distributed to authors of borrowed content. Rather than dividing the funds on a per borrow basis, the payments will now be allotted on a per page read calculation. That is, the total global fund for each month will be divided by the total number of pages read of each author's work during that period, and doled out accordingly.

This has significant implications, both with regard to the benefit of enrolling in the lending programs, as well as to the creation of new content. It will now be vastly more advantageous to add pages to your work (as far as Amazon's program is concerned, at any rate), rather than releasing shorter pieces in order to get more titles borrowed. And while we all would like to think that book content is produced solely by authors who care only about the work itself and not the monetary benefits, one truth I've learned during my years of successes and failures as an author is that writing books is a business, and the authors who are most successful approach it that way, producing content calculated to bring the greatest return on their investment of time and energy. The Kindle lending programs have become a pivotal part of that return for many, dispensing tens of millions of dollars to authors every year - many of whom have been utterly ignored by the traditional publishing machine.

The key factor in this change is that a single ebook that is borrowed now returns an investment more in line with the amount of work it took to create it. A short novella of 100 pages will be paid a rate one third of that received by the author of a full length 300-page novel, and 1/6th the royalty allotted to the author of a 600 page book that likely took an equally longer time to write - assuming, of course, the whole book is read from start to finish.

And that is the other crucial component of this change.

Just borrowing and sampling a book is now no longer enough to trigger a full payment to the author of that work; instead, Amazon's "Big Brother" ability to monitor the status of all content on the Whispersync web (created ostensibly to allow a user's account to sync a title across all of their devices and reading apps) gives them the data required to make this change, since they know exactly how many pages have been read in every ebook ever bought or borrowed from them (assuming it has not been hacked and side-loaded by the reader, which at best is a small percentage of the total number). This is one case in which this admittedly creepy surveillance capacity turns out to work in the content creator's favor. If a reader borrows five books, say, but only reads 10% of each (the minimum required to trigger the payout previously), while another reader borrows just one book but reads the whole thing, the authors of those works will receive due compensation equal to what the readers actually consumed.

And as far as I can see, that is as it should be.

One factor that I will be highly interested to see as a result of this is how it affects the per-unit payout. That is, given an equal number of total ebook borrows month to month, with at least some of these now receiving less compensation due not being read completely, logically speaking the remaining titles that are read clear through will receive a higher payout overall than they would have otherwise, since it is based on a total pool of funds that is established by Amazon each month (and drawn at least in part from subscription fees for Prime and Unlimited membership).

This amount has always varied month-to-month, due to seasonal trends in reading, but has ranged anywhere between $1-10 million, give or take, generally averaging something like $2-3 million (this month's being $10.8 million due to a huge $7.8 million bonus). With the establishment of Kindle Unlimited in July of 2014, the per-unit payouts have rapidly declined - dropping from $2.20 per borrow in June of last year (just prior to the KU rollout) to a low of $1.33 in October - due to the increasing number of borrows among which the pool must be shared. My guess is that this is Amazon's attempt to rectify that problem, as well as the dilemma presented by the steadily increasing number of subscription members overall.

The ultimate question is: Will Amazon increase or decrease the monthly payout based on these factors? And more importantly, will authors feel they are being compensated more fairly as a result, or less, and how will they respond?

Thursday, April 16, 2015

Kindle Textbook Creator Updated

Amazon released a major upgrade (1.5.14.0) to the fledgling Textbook Creator app this afternoon that adds two significant improvements: support for embedded audio and video (as well as popup images), and simple table of contents creation. There are also new rulers and guides to help you align the inserted content.

You can find the official announcement here, and download the updated application here. The User Guide has also been updated from edition 1.1 to 2.0, and can be downloaded from the link on the lower-right of the application page.

A quick look at the Revision Notes shows several new sections have been added to the User Guide:
Before looking at the specifics of these changes (and several others that are curiously not listed), I should point out that the files created with KTC are currently only readable on newer HDX Fire tablets, since they are by nature higher resolution fixed layout files that the older (and smaller) Kindle readers are not well suited to view without some means to magnify the text, which KTC does not yet provide - unless you use the new image pop-ups to do so; but this is cumbersome at best, as it employs a clunky icon rather than actual interactive text as in the standard KF8 fixed format. The program outputs the unique Kindle Package Format (KPF) file type, rather than the standard AZW3 or other fixed mobi formats that are supported on nearly all Kindle devices and apps. Note, however, the following detail from today's announcement:
Access to the interactive features in these textbooks...will soon be available on other free Kindle reading apps for iPhone, iPad, Android phones, and Android tablets, as well as Mac and PC computers.
Notice that they do not include any additional Kindle devices, only Kindle mobile or desktop apps. Still, this will greatly broaden the usability of these files, and bring them to the majority of screens most readers of digital textbooks are likely to use. Textbooks are, of course, the intended purpose of this file format, although in the KDP Help Topics the listing for KTC is found under the somewhat ambiguous heading Publishing Illustrated Content. Even more confusingly, this page has long had interactive content listed as available in this format, even though it has not been until today. But then, this is hardly the first time Amazon has gotten ahead of themselves: note that the KTC Beta page already states that the KPF format can be read on all of the Kindle free reading apps, which is dramatically enforced by the included promo video. Note, though, that the page still lists the app as being in Beta.

In addition to the output format issue, your source input file for the page layout can still only be PDF, either as single or multiple page files. Individual pages can be added or deleted, but you cannot change the page layout from within the program; it is solely used to compile the source files into a Kindle-compliant output format - though now, of course, you can also embed multimedia content in those pages. And that is the big news here today, as outside of reflowable ebooks in the Kindle for iOS app, this is the first time that media files have been supported on the Kindle platform. So let's take a closer look at some of those details.

1.1 Import Format

Kindle Textbook Creator now supports the addition of the following multimedia file formats:
  • Video: .mp4
  • Audio: .mp3
  • Images: .jpeg or .png
Images can now be embedded as "figure pop-ups" to supplement whatever graphic content is already designed into the PDF source file. These and the audio/video content are displayed as icons that can be placed wherever you would like them on them page by simple drag and drop. Tapping on the icon in the published ebook will activate an internal plug-in that will play the content. Additionally, when previewing the packaged content, the interface provides you with a preview of the currently selected file in its native plug-in. But more on this in a minute.

1.2 Export Format

Even though it is not listed in the Revision Notes, a new paragraph has been added to this section that could use a bit more explanation. In essence, it says that you can update a KPF file on your KDP content page, so long as it was initiallyt created using KTC - presumably you would want to do this if you go back and add new interactive content to a title you have already published - but, if you create a new version of a title published in a different Kindle format you will have to publish it as a new title.

Unfortunately, that is all the information that the User Guide provides. However, if you go to the Help page for this topic you will find some additional (and rather critical) details, including a link to the KDP Customer Support contact page that you can use to have them link that new edition of your work to the previously published version, so that you do not lose accumulated reviews, etc. But as it states on the Help page, sales rankings for the two editions will still be calculated separately for each.

1.3.2.1 Rulers and Guide Lines 

As mentioned, there are now guide items to help you align your embedded content on the page. There is a Show/Hide check-box on the View menu that surrounds the Document Window with rulers, and if you hover your mouse over one of these you can click and drag out guide lines for horizontal and vertical alignment. A tool tip tells you the current position of your cursor. Units are in Points, which unfortunately I can see no way to change. Grab a guide line with your mouse and drag it to the ruler to remove it.

1.3.3 Properties Panel (Previously titled "Right Panel")

The newly renamed Properties Panel on the right is where you'll find the new option to add a page as a linked location in the Table of Contents, as well as all the functions for adding and editing your interactive content. A couple of screenshots give examples, which we'll look at further in the sections below. The panel content here changes depending on what is selected in the windows on the left.

1.4 Keyboard Shortcuts

Rather than listing "Delete Page" as the Action for the Delete keyboard command, the new edition of the User Guide gives it as "Delete Plug-in" instead. This means you can no longer use the keyboard shortcut to delete unwanted pages from your project by highlighting them in the Pages Panel on the left and simply hitting the delete key, but must now use the option in the Edit menu drop-down instead, or right-click on the page thumbnail on the left to bring up a context menu that contains a Delete Selected Page option. In a way this is really best, since it keeps you from deleting a page by mistake when you meant to delete a plug-in that you thought was selected instead!

2.3 Building Your Table of Contents

This new section details the fairly simple and straightforward task of adding pages to a Table of Contents. As mentioned earlier, a new check-box in the Properties Panel provides the option to "Include Page in Table of Contents" whenever a page is selected, along with a box in which you can include a Page Title label of up to 100 characters for each entry.

Bear in mind that this does not create an actual TOC page, but only produces the Kindle device menu links. These can be seen (and tested) when you preview your project by selecting a new icon at the bottom of the Inspector. Select the little device icon on the left to return to the Preview options tab.

2.7-2.11 Plug-ins

Five new sections have been added that go into all the gritty details of adding and editing the three new media types that KPF supports. I won't go into all the specifics here, since that is the purpose of the User Guide, and it's all a fairly intuitive process. Amazon has provided new options for adding media files in a couple of places: from the Edit > Insert Plugin menu drop-down (where there is also a Delete Plug-in option), or from the Insert icon in the menu bar next to the Undo/Reco icons. As mentioned earlier, you can also delete the plug-in by selecting its icon and either hitting the delete key or right-clicking to get the option from the context menu.

When you add a media file you will get a suitable file type icon which you can drag around the page to a suitable location. In Amazon's delightfully annoying editorial style, they have provided an entire new section (2.8) of nearly a page in length to state (in four numbered steps) that you can change the location of an icon at any time if you change your mind.

Once you have added a media file icon to your page (or selected one already there), the Properties Panel on the right will provide you with a number of options, as well as a bit of info about the file, including its size. An important note on this point is that the KDP file upload size is limited to 650 MB (a restriction that was recently increased substantially from its previous 50 MB limit), and should you attempt to insert a file larger than this you will receive a warning that the file exceeds the allowed size. However, you will not receive a warning should two or more files exceed this size! It will, in fact, actually package the project and produce a file that will not be accepted for upload to the KDP portal.

Below the file info is a Replace button that allows you to exchange the current file with another, and below this there are several text entry boxes for adding a title and descriptive content to your media. Again, this is all very simple and straightforward, and does not even require reading the User Guide.

3.1 Previewing Your Book

Just a slight bit of elaboration has been added here to explain the new TOC and Device icons and their respective tabs, as mentioned above.

3.3 Uploading Your Book to KDP

Another reiteration of the KPF file replacement protocol has been added here, which adds nothing new to what was said above. The hyperlink to the KDP webpage has been removed from the Properties Panel (as has all of the previous Help text found there) and moved to the Help drop-down menu instead. The remainder of this section is the same.

Conclusion

While KTC is still clearly a Beta program with few frills and even fewer customization options, this first update makes a very significant leap in terms of content. The possibilities of what can be done with interactive media in a Kindle fixed format file have improved three-fold at one fell swoop, although it would be far more useful were it also available in the far more developed, and EPUB-based, KF8 format, rather than the PDF clone stamp that it is. But most average content creators don't have the time or interest in learning HTML/CSS coding, so the PDF input is a plus for them, making it easy to create print and ebook editions from a single file - one that can now quite easily have bonus content added in its digital incarnation. The icon-driven UI leaves a lot to be desired - particularly when held against the graceful interface produced by iBooks Author. KTC is clunky and old-school in many ways, but it's simple and it's easy, and for many users simple is best.

Tuesday, December 23, 2014

Kindle Publishing Guidelines 2014.3

The latest update to the Kindle Publishing Guidelinesis out, with a lengthy change log that includes a few important changes. While consisting primarily of editorial revisions to specify which Kindle device a given formatting recommendation applies to, there are two specific changes to Kindle content production that are significant, these being sections 4.3.7 and 4.3.9 as given in the Revision Notes shown above.

4.3.7 Recommendation #7: Do Not Include an HTML Front Cover

The first of these reverses a long-standing error in Amazon's Kindle production policy. Until now this section heading read Include an HTML Front Cover, while it now emphatically says not to (as I have long advocated). Including one has always resulted in two cover images appearing, causing reader confusion due to the apparent unresponsiveness of the first page turn. Moreover, there has never been a good reason to include an HTML cover page, since all Kindle devices and apps render the jpeg cover image correctly, as well as using it for the bookshelf image.

As the Kindle Publishing Guidelines itself now states:
While Amazon previously recommended an HTML front cover page for fixed-format books, this is no longer necessary. 
Kindle books should only have one visible JPEG cover. This cover should be a high-resolution JPEG image that has the same level of quality as the subsequent pages. Any instances of HTML cover pages should be deleted to avoid a repetition of the cover image.
Presumably the HTML cover page was originally included in order for the Guide to point to the cover as the first page the reader sees, if this was so desired (since it could not point directly to an image at that point, as it now can). But since the implementation has been inconsistent, opening to the jpeg image in many cases, as well as the reader being able to swipe back to the cover image anyway, this has caused confusion and frustration for many readers.

The recommendation to include a high resolution cover image is now all the more important, since it will be rendered as a full page image on first opening.

4.3.9 Recommendation #9: Do Not Include Start Reading Location

This is an entirely new addition which addresses an ongoing issue with the first page to which a Kindle ebook opens on first reading. This has been erratic and seemingly random, since the same ebook would open to different pages on different Kindle iterations, depending on a number of confusing factors (including, among other things, the appearance or absence of a "toc" entry in the Guide, as detailed on pages 74-5 of my Kindle formatting manual).

While Amazon has repaired several of these errant instances, some have continued to persist (such as the perplexing inability of the "Go to Beginning" entry to open at Page 1). This issue is now eliminated with the newest Guideline recommendation:
In Kindle fixed-format books, the OPF file should not include the start reading location (”Go to Beginning”) guide item. Amazon now sets this guide item to the JPEG cover for Kindle fixed-format books.
All fixed layout Kindle ebooks will now open to the cover image (which should now only be a jpeg image), rather than to the title page, the table of contents, the first page after the table of contents, or any other random location in the publication. This provides for a consistent user experience across devices and platforms, as should have been the case all along.

Note that Section 3.5.1 on "Recommended Guide Items" still lists the "Go To Beginning" entry as a valid item. This is likely an editorial oversight, but since the removal of the start reading Guide item is only a recommendation, the entry is technically still valid, though not advised.

Note also that you can still include a "bodymatter" element for the start reading location in the Landmarks section of a nav doc, though this will not affect the page to which the book first opens, but only create a linked menu entry to the chosen page.

2.2.2.3 Using KindleGen

Among the other changes made in this edition is the inclusion of Dutch as an optional language in KindleGen (using the locale option nl during conversion).

3.6.3 Image Guideline #3: Use Color Images

Removed the line describing the difference between eInk and color tablet devices, and added a statement that photographs must be in the jpeg format. Specifically, the line removed stated that:

The Kindle e Ink devices currently have a black and white screen, but color is available on the Kindle Fire, Kindle for iPhone, and Kindle for PC.
This is curious, since the removal of the reference to a greyscale display hints at the coming of a color eInk screen. Although this has long been awaited, to date there is no evidence that a reflective color display is forthcoming, and we have already missed this year's pre-holiday release window, so presumably it won't appear for at least another year.

The appended statement that photos must be formatted as jpegs is followed by further image clarifications in the next section.

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

This entry has been extensively revised to make it adamantly clear that line-art and text images should not be formatted as jpegs, which blur sharp edges when adding compression, but should instead be embedded as either gifs or png files, which preserve crisp edges - and even enhance them, in the case of gifs, by reducing color values and grayscale contrast (as the added line "including black-and-white drawings" makes clear).

One line has been removed here that bears comment:
The automatic conversions applied by KindleGen are best avoided.
This statement was always inaccurate in this context, since all supported image formats are converted to jpegs during the KindleGen conversion, and therefore cannot be avoided. What was meant instead was that the cleanest possible image should be input in order for KindleGen to apply the best conversion possible. If an already compressed jpeg is embedded, its quality will only get further reduced by the additional compression applied by KindleGen when converting to the low Mobi 7 image standards.

This requirement is emphatically repeatedly in this section several times, culminating in the conclusion that
Amazon insists on GIF or PNG file formats for line-art.
Finally, a lengthy section has been added to the description of the MINIMUM size requirements for lines of text contained in images (which is 6 pixels for a lowercase "a"), including the addition of a new example image:
The added text states that the image should be taller than the 6 pixel text itself, such that
the image should be at least 45 pixels in height so that it displays proportional to surrounding text content.
This assumes, of course, that the surrounding text content has not been modified by the user's font size and line height settings, but the intention is clear: make your text images big enough that they can be clearly seen, and leave some margin space around them so they preserve the line height and don't encroach upon surrounding text.

6 Audio and Video Guidelines

Several additions have been included to reiterate the fact that, no, audio and video is not supported on eInk devices, and KDP does not accept Kindle Editions with audio/video content included. Still.

This is simply a shortcoming of the slow refresh rates of eInk screens (and one of the primary reasons reflective color displays have not been adopted), although why audio is forbidden is beyond me. Probably for the same reason Amazon stopped bothering to include speakers, or even a headphone jack, on the eInk devices. Or perhaps because of it.

9 Kindle Best Practices

Here again some lines have been removed, and the terms "e Ink" and "tablet" inserted to more clearly differentiate between the two. There is also a revision of the formats supported for viewing on devices and in Previewer, via the removal of two lines.
The Kindle Fire device view displays the content in Kindle Format 8.
This applies to Previewer, and was probably removed due to the fact that it is no longer relevant, since virtually all Kindle devices now support KF8, and Previewer displays content as such.
You can test Mobi 7 content on a Kindle e Ink device and on Kindle applications for PC/Mac/Android.
This line was made more or less redundant by the fact that Mobi 7 content is now only sent to the oldest of the old Kindle devices, and is very likely soon to be eliminated. Moreover, there is no way to actually chose which version of the converted file is being tested, since the device reads whichever one it has support for. Again, virtually all Kindle devices now read KF8, so the distinction is no longer relevant.

The subsequent line that stated KF8 could only be tested on the Kindle Fire has also been appended to include the eInk devices, but interestingly not the apps. This implies that you can no longer use (or rely on using) the desktop and mobile apps for testing files, which is sound advice, since they are the least consistent in rendering content correctly, or supporting features. Best Practice is, and has always been, to test on an actual Kindle device, followed by Previewer, and only as a last resort to use a desktop or mobile app (although the Android app is better than the other apps by far, as far as feature support goes).

All in all, these updates pave the way for future moves away from the outdated Mobi 7 format and into feature-rich KF8 support across the board (more or less), and address some outstanding issues with the format itself in order to make the reading experience more consistent.