R. Scot Johns's Blog, page 6

Kindle Update Adds More Language Support

Looks like the three newest Kindles are getting software updates today. It's always a surprise one of my sleeping readers suddenly turns on by itself, like some kind of dormant ghost in the machine awakening. Today's update is coming to the HD8.9, HD7, and the 2nd generation Fire (sorry Paperwhite!), and adds four new or otherwise improved features.


1) Language Support for Brazilian Portuguese




In support of Amazon's recent foray into the heart of South America - home of their namesake, the behemoth river Amazon - this new update adds the ability to change the native device language to Brazilian Portuguese. Amazon opened the Kindle Store in Brazil last December (amazon.com.br), with the Kindle devices themselves arriving shortly thereafter, as well as expanding KDP distribution to the Brazilian market at the same time. And while there are over 13,000 titles available in Portuguese on the Brazilian Kindle Store, the three newest Kindle devices are only now getting support for the language. Slight faux pas there, but better late than never I suppose.




2) New Keyboard Languages




You can now also change the language and layout of your onscreen device keyboard to any one of 37 additional languages, thereby allowing you to communicate in your own language! At right is a screen cap of the new Norwegian keyboard, which adds a few additional glyphs, as well as changing the spacebar name to its equivalent in the chosen language. This will greatly improve the usefulness of the device for a far broader audience, for everything from searches to notes and comments. 




To add new keyboard languages, go to the Settings menus and select "Language & Keyboard." Tap the "Keyboard" option, and you will find a new option to "Download Keyboard Languages," which takes you to a list of 37 additional choices beyond the twelve or so default options. Once you download the language of choice, you will find it available as a choice when you press and hold the space bar on the keyboard. The Keyboard section of the Settings menu will still show only the default languages that shipped with the device.




3) Multicolor Highlights




Notice on the screenshot to the right that there are now three additional color choices when you tap a word to bring up the dictionary popup. Rather than the standard yellow highlighter, you can now choose from Pink, Blue, or Orange as well. As an author I'm a big fan of multicolor highlighting, for everything from research to outlining, and I can easily imagine this becoming a favorite feature for those who use Kindle Print Replica Textbooks for their studies. Even if you borrow a book, you can add you own highlights to it, and they won't appear to anyone but you - even when you borrow (or later buy) the book again! The beauty of digital highlights is that you can erase them with a tap, and the content is none the worse for wear.




4) Share Notes & Highlights from a Print Replica Textbook




And speaking of Print Replica Textbooks, you can now share any notes or highlights you might make in the text at hand by emailing them to classmates, or anyone else who has that same book. I've never actually seen a Print Replica Textbook, so I can't tell you how well this works, but I imagine it's little more than an additional option on the popup menu, probably under "More..." or as an option when you tap on Note or Comment. The value of this will be obvious to students in study groups, and I hope they add it to standard books as well, since it would be highly useful for reading groups as well. The option to broadcast your comments to the universe at large via Facebook and Twitter is fine for general use, but directly sharing notes and comments would be greatly welcome in the interconnected global world we all now live in.

iBooks Tutorial Update: Version 3.0

I've been meaning to do an update to my iBooks Tutorial series for about five months now, ever since Apple released "Revision 1" of the iBookstore Asset Guide 5.1 back in February. But being deeply buried in the Kindle Fixed Layout Tutorial at the time, I've only now found time to address it.




Many of you many have already read the updated Guide, or looked at Apple's new 3.0 sample files, and been confused about the absence of the com.apple.ibooks.display-options file, or some of the new metadata properties found in the OPF and the fact that the NCX is missing. These are just a few of the changes made to the iBooks format that we will discuss here. 




So with that, let's look at what's new in iBooks!



NOTE: All mentions of the "iBooks" format refer to the .epub file format, and not the .ibooks format, which can only be created using iBook Author. Much of this discussion applies to that format as well, but its implementation is entirely dependent on the iBooks Author tool, and so no relevant here.




EPUB3 Additions




First, the most notable alteration made to the structure of an iBooks fixed layout file was the removal of Apple's proprietary com.apple.ibooks.display-options file, which previously controlled the overall layout and functionality of the fixed layout properties for the publication. This change was made in order to incorporate the portion of the EPUB3 specification that pertains to these attributes, thus making it easier for ebook creators to produce an iBooks file based on common ePub standards.




These features are now contained within the OPF file, along with all the other relevant package metadata, and rely upon EPUB3 nomenclature and semantics. Amazon, incidentally, has also incorporated a small portion of the EPUB3 spec into their Kindle format. Thus, for those of you who have read my Kindle fixed layout tutorial, some of what's to follow will be familiar.




It should be pointed out here that the com.apple.ibooks.display-options file is still required for "Version 2.0" iBooks files, as the new EPUB3 code is fully functional only in "Version 3.0" ebooks, which, of course, also requires iBooks 3.0 or better. Therefore, if you want to produce strict 2.0 ebooks for backwards compatibility, none of this applies. However, going forward you should create iBooks 3 compliant files, for future compatibility.




Version 5.1 of the Asset Guide removed all references to the EPUB2 file structure, so Apple is not looking back on this one. For info on the EPUB2 file structure you must resort to Version 5.0 or earlier of the Guide (or my iBooks tutorial here on this blog). Files built using EPUB2 will currently run just fine in iBooks 3, of course, but will become outdated sooner as iOS and iBooks continue to be updated.




So with that out of the way, let's look at the specifics of what's been changed...




[By the way, if you're interesting in seeing what has changed in the EPUB spec itself, the change-log can be found here: EPUB 3 Changes from EPUB 2.0.1.]




EPUB3 METADATA




In order to define your publication as an EPUB3 compliant file, the first thing that you need to do is declare the version number in the header of the OPF:

<package xmlns="http://www.idpf.org/2007/opf" version="3.0">

And although this is not EPUB3 related, while we're up here messing in the header I should point out a set of new declarations that have been added:

prefix="rendition: http://www.idpf.org/vocab/rendition/# ibooks: http://vocabulary.itunes.apple.com/rd..."

These define the semantic rules used by some of the new additions, including media overlays and javascript. If these are not present in the header your ebook may fail validation.




With the com.apple file gone, the entries that define your layout options are now found here in the OPF metadata section along with the title, author, publication date, etc. Incidentally, the "modified date" is now listed for the first time as a required item (along with the title, identifier, and language):

<meta property="dcterms:modified">2012-05-04</meta>

Apple (like Amazon), has incorporated three new EPUB3 properties into the OPF, which are defined as rendition attributes, although Apple has also included a few ibooks-specific entries as well. First, of course, is the entry that defines the publication as a fixed layout:

<meta property="rendition:layout">pre-paginated</meta>

This replaces the "fixed-layout">true/false option in the display-options file. Options here are "pre-paginated" for fixed layouts or "reflowable" for flowing ebooks. This is obviously required for fixed layouts.



Next, there is a replacement for the "orientation-lock" option in the com.apple file:

<meta property="rendition:orientation">

values for which are "portrait", "landscape", and "auto". Note that the values are not "portrait-only" or "landscape-only", although "none" is a valid alternative to "auto", and is the default value.



The third and final EPUB3 entry is more-or-less (though not exactly) the equivalent of the earlier "open-to-spread" option:

<meta property="rendition:spread">

Here the values specify whether the viewport displays a one or two page layout. Allowed values are "none" for a single-page layout in either orientation, "both" for two-page spread in either mode, and "auto" for a "best-fit" option that displays one page in portrait and two in landscape for standard aspect ratio layouts, and the reverse for wide page layouts. This last, however, does not always work as intended, and in fact, Apple list it as a two-page spread option. In addition, the EPUB3 spec allows the values "landscape" and "portrait" in order to force two page spreads in the given orientation, but iBooks does not support these.



One additional EPUB3 metadata property will be addressed in due course, but these are the three that effect the ebook functionality.


IBOOKS METADATA



In addition to the above properties, Apple have included a few proprietary entries to define some of the other iBooks-specific attributes previously found in the deprecated display-options file.



The first of these functions as something of an addendum to the rendition:orientation property, and replaces the "platform" tag in the com.apple file, which allowed for setting separate values on the iPad and the iPhone/iPod Touch. Here the entries are given as:

<meta property="ibooks:ipad-orientation-lock">

<meta property="ibooks:iphone-orientation-lock">

where the value is either "portrait-only" or "landscape-only" (as they were in the display-options file). If provided, these values override any global settings entered in the "rendition:orientation" entry (if given), allowing you to define layout preferences for three separate scenarios, which becomes more relevant now that OSX will finally get iBooks. If no platform-specific values are entered, of course, the global settings will apply.


Next is the substitute for the "specified-fonts" property, which is now given as:

<meta property="ibooks:specified-fonts">

valid values for which are true or false. If you include embedded fonts in your publication this must be provided and the value set to true.



Finally, Apple has added an entirely new property with this latest iteration, one that has not been available before:

<meta property="ibooks:binding">

This allows you to turn off the faux book binding if you so choose, by entering a value of "false". This will also remove the shadowed "spine crease" that runs down the center of each two-page spread. The value is set to "true" by default.



One other property must be mentioned before moving on, and that is the now-deprecated <option name="interactive"> element found in the com.apple file (though little known and rarely used, it seems). This has been supplanted by the script tag, which is inserted directly into HTML pages where javascript is present. Scripted code, however, is a complex subject which demands its own tutorial, so I'll leave it be for now.




THE MANIFEST




Moving further down the OPF, there are two new additions to the manifest portion of the file, both of which have also been adopted by Amazon. Each of these add a property value to a listed item which identifies its function in the EPUB3 schema. The first of these defines the cover, and is appended to the line listing the cover image file:

properties="cover-image"

This replaces the <meta name="cover" content="cover"/> entry in the metadata section of previous ebook files. You can leave it in or delete it as you see fit.




The second property defines the new Navigation document, and again is appended to the relevant line in the manifest section of the OPF:

properties="nav"

We will look at the Nav doc momentarily, but for now just be aware that you must give this property in order for it to be recognized by the reading system. In addition, because the NCX has been replaced by the Nav doc, you obviously no longer need to add the toc="ncx" attribute to the Spine tag.




Finally, one last change has been made to the OPF that must be mentioned before moving on, and that is the complete removal of the Guide section, which has been replaced by the new EPUB3 Navigation document.




The NAV Doc




New in version 3.0 is the addition of the EPUB3 Nav doc, which supplants the outdated NCX. The Nav doc is simply an XHTML file with some unique entries, each of which we'll look at in turn. The nav tag is an HTML5 element, and therefore is not supported in EPUB2. Again, Amazon has added support for portions of the navigation doc to the Kindle format (excluding the page-list attribute), so if you've got my Kindle formatting guide be sure to read that section for more info on this subject.



First, be sure to add the new prefix declarations to the Nav doc header, in addition to the standard idpf namespace:

xmlns:ibooks="http://vocabulary.itunes.apple.com/rd..."

epub:prefix="ibooks: http://vocabulary.itunes.apple.com/rd...

Note that these both reference the same place, just using different syntax. These are required to define the rules of semantic usage for the entries in this page.




There are three sections of the Nav doc: the toc, landmarks, and page-list, each of which are given as an epub:type within a nav tag.




THE TOC




The first and primary section of the Navigation document is the Table of Contents, which provides the reading system with a list of entries and links for the contents menu. This is the only required element in the Nav doc in all cases (landmarks are required in given situations, which I'll get to, and page-list is not required in any instance). This section replaces, and greatly simplifies, the content of the NavMap in the superseded NCX.




Please note: the Nav toc is not the same as an internal HTML Table of Contents within the book itself, although it can be if you list this file in the Spine (which will make it show up in the linear sequence of the book); however, it's better to create a separate page for internal TOC's, since the other content in this file will also appear on the rendered page, which you undoubtedly will not want. Thus, unfortunately, the Nav doc does not provide a means of creating one universal TOC for all purposes.




To define the TOC section, add a nav tag with the following values:

<nav epub:type="toc" id="toc">

Note that the epub:type value is case-sensitive, so it must be "toc" and not "TOC" or any other variation, in all instances where it appears. This is true for each of the three values given on this page, which use all lowercase letters.



The id value can be anything you like, so long as it matches what you enter in the OPF manifest for this file's id, otherwise the reading system will not find it. This is the only section of the Nav doc that requires in id value.



All three of the sections give their entries as an ordered list (with or without a header - you can add one if you like):

<h1>Table of Contents</h1>

<ol>

        <li><a href="page.xhtml">Entry Title</a></li>

</ol>

One, and only one, ordered list can be included in each nav section.



List each entry in this manner, providing a link to the file name and a title. The file name can be appended with a fragment (#name) linking to an anchor on a page, but of course in fixed layouts this is not really necessary, since the full page is displayed, unlike flowing files. The text you enter between the angle brackets (> <) will appear as the table of contents entry in the menu, exactly as given, so be sure to use correct capitalization for these, as well as the header if given.



Do not add page numbers to these entries, as iBooks will add them automatically, using the values given in the page-list, if provided, or simply number them sequentially if not.


Finally, be sure to close each line item individually, as well as the ordered list at the bottom and the nav section itself (</nav>), since each section requires its own nav tag.



LANDMARKS




The landmarks section of the Nav doc replaces the deleted EPUB2 Guide items in the OPF, providing structural information about the content. However, unlike Amazon's clearly defined functions for the three entries the Kindle recognizes, the purpose of this section in iBooks is more or less opaque. With the sole exception of the "bodymatter" attribute, none of the myriad entry values available have any effect on a publication's functionality.




That said, you are required to provide a "landmarks" section with at least the "bodymatter" attribute included if, and only if, you do not provide a custom sample file for your ebook to the iBookstore during title setup. If one is provided by you, the landmarks section is not required. The reason for this is that Apple uses the "bodymatter" tag to locate the start of the sample it creates automatically if one is not provided by you. Apple recommends you include landmarks for all structural components in your ebook (i.e. preface, dedication, appendices, etc.).


To create a landmarks section, add a new nav tag with the following attribute:

<nav epub:type="landmarks">

Within this include an ordered list as you did in the toc section, with each line item containing the following attributes:

<li><a href="page.xhtml" epub:type="value">Irrelevant Text</a></li>

Again we have a referenced link to the page location, but in this case we also get a second embedded epub:type attribute for each individual line, the values for which are nearly endless. You can find an exhaustive list of possible values on the EPUB 3 Structural Semantics Vocabulary page at the IDPF website, where something like 70 entries are given, detailing the component parts of nearly any given document. And here again the values are case sensitive, with entries given in lower-case.




Note that you can only include one line item for each epub:type, so for example, you cannot add multiple items with the "chapter" value, even though you may have many chapters. This is more the function of the Table of Contents. The purpose of the landmarks is to distinguish significant sections of a publication, such as its front or back matter, from its main content. 




As I mentioned, only the "bodymatter" attribute has any stated functional value in the Asset Guide, although others may be used to pull data at some point in various reading or distribution systems, so it certainly can't hurt to add it. The "bodymatter" link should point to the first page of actual content in the book, after any frontmatter that's been included.




On that note, there is one other entry that Apple has added which has a unique epub:type all its own:

epub:type="ibooks:reader-start-page"

This sets the "start reading" page to which a book opens on first reading. This applies only to flowing ebooks, but this is where you would add it if you were making a reflowable file, so I thought I'd mention it at this point.




Lastly, with regard to the "title" text provided for these entries, there is no purpose to it whatsoever, as it shows up nowhere, does not contribute to the entry's functionality, and in Apple's examples generally just repeats what is given as the epub:type value. Whereas the Kindle creates active links from the contents of the landmarks section for some of its "Go To" menu entries, iBooks has no such feature, so aside from the sample file function, there is no practical reason to include this section in the Nav doc at all.




But again, it may show up in databases somewhere down the line, such as those used by libraries or retailers, and as always, more information is better than too little.




PAGE-LIST




The final section of the Nav doc provides page mapping functionality. This allows you to asign page numbers, Roman numerals, or letters to any given page, rather than have them simply numbered sequentially in the device menu Table of Contents. iBooks pulls from this list for the page numbers given in the TOC, if supplied.




In addition, these show up at the bottom-center of the screen, just above the thumbnail scrubber, when you tap the display to access the menu bars, and also in the larger thumbnail when you scrub through the images. They do not show up in the actual image grid version of the TOC, but they do appear on any bookmarks the reader adds.




To create a Page Map, add a new nav section with the page-list attribute:

<nav epub:type="page-list">

And again include within this an ordered list containing links to each page:

<li><a href="page.xhtml">#</a></li>

You can add any alpha-numeric character you like (1,2,3 - i,ii,iii - I,II, III - a,b,c), using capitals or lower-case, or you can leave it blank for an unnumbered page. You can even enter a short word or phrase, such as "Intro" or "fig.1" (although this is best left to a Table of Illustrations). Page numbers are probably more useful, but whatever you use keep it short and relevant.




This is the one feature of the Nav doc that Amazon opted not to incorporate for some reason, possibly because the Kindle has no thumbnail function. But it would be nice to have page numbers in the menu TOC, as this would make using the "Go To Page" function much more useful!




Other Additions




A few additional EPUB3 features have been included in the Version 3.0 format, which I will outline here. These include the ability to add pop-up footnotes (very cool!), change both text direction and page progression, including Tatechuyoko integration (critical for many non-western languages), and adding version numbers in updated editions (which automatic customer notifications of the changes!). These are all significant improvements to the platform, so let's look at them each a little closer.




POP-UP FOOTNOTES




EPUB3 provides an easy means to create active links that trigger a pop-up overlay containing additional content. This is intended to be used for footnotes, but of course can be used for many other reasons, much in the way I used the Kindle magnification function to create many types of interactive features. I have not yet tested this to see how far it can be pushed (as, for example, to what extent the styles can be modified via CSS), but so far as I can tell there is no reason why you could not do much the same with this code.




To create a basic pop-up you need two elements: a link and a target. First, you create the active link using a standard anchor, but with the addition of an epub:type attribute applied:

<a href="page.xhtml#name" epub:type="noteref">Content to be linked</a>

For footnotes the "content to be linked" is generally a numeric digit of some variety, although it can really be anything, even an image, since the "noteref" simply functions as a trigger to activate the target. You can add a class to style the link as well.




For the target content you use another epub:type attribute contained within an <aside> tag:

<aside id="name" epub:type="footnote">Content for the popup</aside>

This hides any content held within the <aside> tags until the link is activated. Note that the id value must match the fragment in the anchor reference (#name in this case). IBooks applies some default styling to the pop-up, but you can override this to some extent with your own custom CSS classes. Again, I have not yet tested this thoroughly, so you'll have to try it out yourself to see what works.




Also note that any page which includes an epub:type attribute must contain the epub namespace in the header declaration:

xmlns:epub="http://www.idpf.org/2007/ops

This, of course, is in addition to any other declarations required for the content on the page.




PAGE & TEXT DIRECTION




As I mentioned earlier, you can now define both the text direction and the page progression in order to accommodate vertical and/or right-to-left languages. Page turn direction is, of course, a global setting, since it defines where the ebook starts and ends. This is set by adding an attribute to the Spine tag in the OPF:

<spine page-progression-direction="rtl">

Since the default value is left-to-right, you only need to add this if you wish to alter the page direction, although you can technically add the value "ltr" if need be (say, for example if you're working with an Asian version of iOS that has a default of "rtl"). In addition, you can enter the value "default" to let iBooks define the page progression, based on the system or reader settings, in the event your title has multi-language support (in a technical document or instruction manual, for example).




Text rendering can also be determined by adding a dir attribute to the package header in the OPF in order to define a global text direction:

<package dir="rtl"...

Again, the default is ltr, so you only need to add this to change the default behavior to produce a right-to-left text direction.



Vertical text is also now supported, but this is done at the page level using the CSS3 writing-mode property:

-epub-writing-mode: vertical-rl;

This allows you to create individual pages with alternate direction text, if so desired. Allowed values here are vertical-lr, vertical-rl, and horizontal-tb (top-to-bottom). This must be added to either the <body> tag or the <html> container itself for each page. Thus, only one value can be applied to each page (or content file in the case of a flowing ebook). You can, however, add section of alternate-direction text ("Tatechuyoko") using a class with the "text-combine" attribute applied:

-webkit-text-combine: horizontal/vertical;

You then append that class to the section of text to be displayed in the alternate direction. In this way you can add both horizontal and vertically aligned text to a single page.




VERSIONING


You can now add a version number to your title in order to distinguish a new edition, with either major or minor changes. Readers who have purchased the book will be notified automatically that an updated file is available, and upon download the new version will replace the earlier one.



The version number is added as a metadata value in the OPF, along with the other new properties mentioned at the top of this post:

<meta property="ibooks:version">####.####.####</meta>

The data string provides for up to three sets of four numeric digits separated by dots. Non-numeric characters are not allowed. The first set signifies a major revision or edition change, as from version 1.x to 2.x. The second set would represent a relatively important alteration and/or addition to the content, while the last set is used for minor changes such as stray typos or non-content modifications to the file structure or layout. Thus, a version 1.1.1 ebook would have seen one minor and one moderate update, but not yet been revised or rewritten to the extent that a new full edition update is required.




The inclusion of the version number property also requires adding the prefix attribute to the package header, just as in the Nav doc mentioned earlier:

prefix="ibooks:http://vocabulary.itunes.apple.com/rd...

Be very careful not to confuse the header version="3.0" attribute, which defines the EPUB format version on which the publication is based, with the ibooks:version metadata property described here, which signifies the current edition number of this particular title.




CONCLUSION




That pretty well covers it for where we are with the iBooks version of the EPUB3 format, which with this revision has moved much closer to a common open source platform than ever before. The removal of the com.apple file and inclusion of standard properties with far broader support goes far towards making content production a less fragmented process.




It is unlikely that we will ever see a single format that is supported on all (or at least the most popular) devices, since each reading system and hardware device has its own unique requirements and quirks. Moreover, just like any business, platform providers succeed by identifying their product as unique, with features superior to others.




The hope is that these platforms will start to differentiate themselves based on the quality of the hardware and the interface, not by creating proprietary file format, but by how well it displays a file any system can display. The user experience would be greatly improved with the frustration and inconvenience of proprietary file formats removed. 




Happily, both Apple and Amazon have made small, but important steps in that direction with their latest updates.

Trailer For IBE 2013

Trailer for Idaho Book Extravaganza 2013, focusing on the author workshops. A schedule of guest lectures has not yet been released for this year's event, but I will post them as soon as they are listed. You can also find their Facebook page here: https://www.facebook.com/IdahoBookExtravaganza.

Idaho Book Extravaganza

I will have a booth at Idaho Book Extravaganza this year, promoting How To Make Kindle Comics & Children's Books, and talking to anyone who's interested in learning how to create their own illustrated ebooks. I'll have some giveaways and drawings for attendees who stop by, so if you're in Boise on Saturday, the 2nd of November, be sure to swing in to say hello. Admission is free!




My current plan is to give away several print editions of the new book, possibly a few of my first novel, The Saga of Beowulf, and one grand prize ebook formatting package that includes a complete fixed layout conversion of an illustrated children's book or graphic novel of up to 30 pages in length, in order to promote my new ebook formatting services (more info on this soon). 




If you've got an illustrated project you've been working on and plan to have it published as an ebook I'd love to help you get it into shape, whether you do it yourself or are seeking professional assistance. So be sure to find my booth and drop a card into the box in order to be entered to win the grand prize drawing!

24 Hour Sale!

For anyone who hasn't yet picked up my Kindle fixed layout formatting manual, now's your chance to get it at a discount. For the next 24 hours it will be marked down to $2.99 and then will go back up to its normal price forever. I will not be putting it on sale again, so get it now.




This is just a test to see how well Amazon's price point structure and internal promotions work, and also to see if there's anyone left reading this blog who hasn't grabbed the book yet. Remember, the templates are free if you use the code, so you can get all three today for just $2.99. 




Offer good until tomorrow morning only!

Best Bookstore Ever!

This would be my ideal bookstore. All electronic, no wasted paper. Having worked for several years at a big box entertainment retailer, I can't begin to tell you how many books I physically destroyed, "stripping" covers of unsold product to return for credit and pulping the remainder - most of which went in the trash, since this was before the days of recycling.




Nearly 75% of all physical books that are produced end up in the pulp factory, unsold, or are "remaindered" well below wholesale simply to absorb some of the loss. Hard covers, for example, can't be "stripped" for return, since the cost to ship all those heavy cardboard covers exceeds the value of doing so. Most of them are trashed or sold for pennies on the dollar. That's hours of labor and wasted resources producing, shipping, stocking, and storing a product no one wants. And publishers have always been woefully poor at determining what readers actually what.




The great irony here, of course, is that the author of the comic above intended this to be a warning of what's to come if print bookstores disappear. To my mind this can't happen fast enough. I actually haven't set foot in a physical bookstore for over three years, although I work for a book distributor, and still acquire a fair amount of printed books (though these are primarily gifts). What I do as my day job is help publishers find a home for all those extra books they overprinted. So of course, if this non-print bookstore scenario should take place, I'll be out of work.




I read this morning that Books-A-Million - soon to be the largest bookstore in the world if B&N continues on the path they're traveling - will be the second major brick & mortar store to install an Espresso Book Machine, a kiosk-sized printer that can produce a print book to order in less than five minutes (see my posts here and here). Powell's in Portland has one, as do many college bookstores (there are nearly 80 EBMs in place throughout the U.S.), but I've never used one. Apparently not many others have either, since the EBM has floundered since inception, due both to lack of title support and the $100,000 price tag to install a single machine. At that cost you would have to sell a lot of books to pay it off.




Still, POD is one way print books can retain their relevance in the digital-dominated bookstore future that is upon us. First, it addresses the issue of title availability in physical bookstores due to limited shelf space that I previously mentioned, making any corner bookshop into a virtual Amazon with one investment. Even at that price, I'm surprised more bookstores haven't made the leap to print on demand, especially when faced with such gargantuan competition. More importantly, however, POD removes the cost of stocking and storing product no one wants, eliminating much of the expense that is bringing independent (and not-so-independent) bookstores to their knees.




Contrary to popular belief, raw materials are not the biggest expense when it comes to selling printed books: storage and distribution are the two largest expenditures where physical book sales are concerned (discounting the losses accrued due to lack of sales, of course). Books are heavy, and they take up lots of space. Believe me, I know, I heft them around all day. There are entire warehouses and 18-wheelers full of books that are going nowhere but the landfill. And even books that are sold eventually find their way there, after making the long, sad round of .25 cent yard sale bins and second-hand stores first. 




The frank truth is that most books aren't worth reading twice (or even once in many cases), which is exactly what second-hand bookstores are filled with: books that no one wants. Books that are great, that are nicely bound and will be read again, rarely find their way back to a bookstore shelf, much less the landfill. But that's not most books. Most books aren't worth being printed, a privilege that will in future be reserved for only those that are most deserving (who will decide that is a matter for another debate). All those used book stores are just a stepping stone on the way to the book graveyard. I've always disliked used book stores, with their musty smell of rotting corpses and shelves packed full of sad unwanted pages, turning brittle and yellow with age and neglect. It's like an old folks home for books, where they're just waiting to be buried.




At least these days we have recycling. But pixels are so much easier to delete.

Kindle Tools 2.9

Amazon released new updates to both Kindlegen and Previewer yesterday, each of which add important new features for content creators producing fixed layout files. Unfortunately, none of them are entirely successful, or altogether helpful.



First, Kindlegen has added support for page layout properties (i.e. two-page spreads) for pages specified as an image in the spine section of the manifest. In other words, you can define an unembedded full-page image as a page by listing it in the spine, and it will now support the page layout properties just like a standard html page would. Presumably, however, it only does this under the same instances as the standard pages do, which thus far has been limited to just a handful of devices, and only certain circumstances (such as having a "comic" book-type value). I haven't tested this yet to verify if this is true, but will do so and report the results when I have them. I'll also try to add an image-based page spread into the templates as soon as I find the time. Not a significant upgrade, but useful for those who want to produce fixed layouts consisting only of full-page images, with no added features.



Previewer, on the other hand, has had a major update that adds the ability to convert files to the .azk format that is supported in the Kindle app for iOS devices. This finally allows you to transfer fixed layout files to the iPad and iPhone for testing, via iTunes. Unfortunately, while the page layouts work correctly (for the most part), none of the region magnification features are functional in the file I tested. You can pinch and zoom the default tap target content (but not pan and scroll it, which makes this all but useless), which shows that the mag regions are still present, but you cannot access the actual magnified target content. Moreover, there are some errors in rendering page content under certain circumstances, such as when using CSS embedded in the HTML file. Also, a similar error as the relative-positioning issue that currently plagues the Paperwhite is occurring here as well, although in this case the horizontal positioning is functioning correctly, but not the vertical alignment. Further testing is necessary.



At any rate, you can now at least test your basic page layouts on iOS devices to see how they're rendering in the Kindle for iOS app. Hopefully the mag region function issue will be fixed with subsequent updates, since these work correctly in other fixed layout ebooks I've purchased from Amazon and downloaded to my iPad.

The Dark Crystal Returns!

The Jim Henson Company has just announced a call for submissions for a new young adult book series based on the pivotal 1982 film that was a masterwork of puppetry, animatronics, and fantasy world building. Cheryl Henson, daughter of director Jim Henson, has founded a new website at darkcrystal.com, which is currently serving as the central hub for "Author Quest" - a clearing house for information regarding the new project.




All writers - both professional and "aspiring" - are encouraged to submit an original short story or treatment of 7500 to 10,000 words based on materials provided on the site, and knowledge of the Dark Crystal world. Submissions will be accepted from October 1st to December 31st, with the winner contracted to pen a 50,000 novel (the prize being valued at $10,000). Visit the site for the official rules.




At the moment you can download a PDF designed to give potential authors some additional background information on the story world and its primary characters. The series will be a "prequel" set roughly a hundred years after the cracking of the crystal - between the Second Great Conjunction and the creation of the Wall of Destiny. This, of course, means that there will be many Gelflings still around - seven clans, in fact, each with their own specific qualities. Moreover, the divergence between the Skeksis and the Mystics will not be as prominent, or their connection known to the general populace. The Mystics, in fact, are said to be "missing," having withdrawn to the caves of the hidden valley, leaving the Skeksis to rule by deception and terror.




Interestingly, there has already been a graphic novel series set in this time period, but it was not successful. Legends of the Dark Crystal  was a manga trilogy that first appeared in 2007, but was cancelled after the second installment. I haven't read it, but apparently no one else did either (although the few reviews it has on Amazon are good). However, last year the first two parts of another comic prequel,  The Dark Crystal: Creation Myths , was released, with art by Brian Froud and others, and I own both of those, being a huge Froud fan. I highly recommend these as resource tools for anyone who might be interested in attacking this new project, as they provide a wealth of insight into the background of the story world.




Another essential reference is The World of the Dark Crystal, an encyclopedic compendium of info about the Dark Crystal world (and a finalist for the non-fiction Hugo Award), including many sketches and watercolors by Brian Froud, as well as essays on the various lands and their occupants. First published in 1982 to coincide with the original film release, there is now a collector's edition, released in 2003, that includes a reproduction of the original concept treatment used to pitch the story to financial backers. Given the success of that pitch, it would behoove potential authors of the new series to study it carefully.



I would actually love to write this story. It's a wonderfully rich world with enormous potential, and I can only hope the chosen author does it justice. One can only hope a sequel film will be forthcoming if the novel is well done. A new Dark Crystal film using today's technology could truly be amazing, particularly given how "dark" film stories have become of late. When the original film came out in 1982 it was only moderately successful, due in large part to the fact that many parents were afraid of these new "evil Muppets." But with the current spate of "Gothic" novels and movies a film like this would fit right in.



Best of luck to all who enter. I can't wait to read your story!

There & Back Again...

Now that “How To Make Kindle Comics & Children’s Books” is done and has been published, it’s time to turn my attention to the task for which I took this long detour in the first place: creating a fully illustrated novelization of Wagner’s Ring Saga operas. Because this will be a heavily visual project, with over 400 pieces of art involved, I needed to be absolutely sure of what I was doing before I created and finalized the art, so that it’s the correct size and resolution necessary for both print and ebook mediums.

Having already produced a 22-page “proof-of-concept” chapbook last year, I’ve already ironed out many of the issues relating to layout and design, as well as working out a general “look” or style for the piece. That said, this is a work in progress in many ways, and will require a great deal of effort yet to sort it out. For one thing, while I’ve already got the primary draft complete, matching the artwork to the text in a tightly confined space is a page-by-page process, requiring a great deal more revision and concision that the average full-length novel. As readers of my first novel, The Saga of Beowulf, will know, brevity is not one of my strongest qualities. In part this is what appeals to me about writing a story that must fit within a given space: it forces me to choose my words and phrase things much more carefully than I ever have before. A good exercise for any author.

So with that said, my plan at present is to use the “new” blog over at rscotjohns.com as a way to record my progress and post updates for those who are interested in where I’m at with it. I'll continue to use this blog for discussing matters pertaining to publishing in general, and ebook formatting in particular. In addition, I will be creating new “Archive” pages over at the Fantasy Castle Books website, where I will post concept art and story excerpts from the various drafts of the Ring Saga project as it evolves. The website, like the book, is a work in progress, and is in the process of being rebuilt for the third time in a year. Hopefully this one will stay up. 

So far the online store has been a great success, with sales there rivaling – and even exceeding at times – my sales on Amazon. As an independent author, my hope is to build on that trend, and become truly self-sufficient, cutting out all of the middlemen completely (or as much as practical, at any rate), since the path between the author and the reader is now ideally a direct line. But I’ll leave that argument for another post.

In a future post I’ll (re-)introduce the Ring Saga project, and post up some introductory art for those who did not have a chance to visit the old website Archives. I may re-post some of the old Beowulf material as well, if I find the time, but as this project will demand more time than I have already, that will not be a high priority. I will, however, try to keep this blog updated regularly from now on…

As a quick note as to where the project stands at present, my immediate task is to sort and organize the thousands upon thousands of digital models I’ve accumulated over the past few years into something resembling a Props department at an art or movie studio, so that I can actually find what I need when it comes time to build new scenes for 3D rendering. I think I spent half my time searching for the right model or texture set when creating the initial concept art, and I’d prefer not to waste as much time in the future. So a bit of time spent up front re-organizing my content should go a long way to making the whole process more efficient. I’ll talk more about this as I go.

Thanks to everyone who has waited so patiently while I was off dealing with ebook formatting issues, and to those who have purchased the “Kindle Comics” guidebook now that it is done! It will help to fund this next project.

"How To Make Kindle Comics" Now Available In Print

$12.99 - 288 Pages - 6x9 Softcover
ISBN: 978-0-9821538-5-7


Given that I've had a number of requests for a print edition of the new tutorial, I took the opportunity to give CreateSpace a try. I had not planned to put out a print edition of this title, since it's all about creating ebooks, and therefore naturally lends itself to ebook format. But several readers have said that they would like to have it in print format for ease of reference while using their e-reading device for working with the templates or other files, which makes sense.




To that end I had initially produced a PDF, which you get along with the Kindle file when you purchase the title direct from my website (either here or via the Fantasy Castle Books storefront). However, this only partially addressed the issue. So with that in mind I dropped the PDF into the CreateSpace upload slot and polished off a spine and back jacket for the cover. The whole process took barely half an hour, although I did need to make a few adjustments to the inner margins and the size of several images. 24 hours later the proof was approved and available for purchase in the CreateSpace store. It should appear on Amazon within a day or two (they say). Click the image to view the page.




Unlike Lightning Source, which requires you to establish a publisher account, purchase your own ISBN, and charges $70 in setup fees, plus $12 per year to host the file (and another $70 each time you want to revise the files), CreateSpace is completely free. The catch is that the profit share is less per copy. But with no upfront cost CreateSpace is a far less risky way to get a title into print, and all but eliminates the question of whether it's worth doing. Even $70 can be prohibitive for titles that only a handful of readers might ever be interested in, especially when you add the cost of an ISBN, which in this case was $27.50 since I purchased a block of ten for $275.




The print edition comes in at 288 pages in 6x9 Trade Paperback, and lists at $12.99. The interior, of course, is black and white, so all the images are grayscale rather than full color, as they are in the digital editions. But if you send me a copy of your Amazon receipt for the print edition, I'll be happy to forward a code to download the ebooks for no extra charge.