Now that I've been working with KF8's fixed-layout awhile, I thought I'd share a trick or two I've learned in case you're interested. Like Apple's iBooks, KF8 has a lot of quirks and peculiarities all its own, but if you learn the way it works then you can often find a way to bend the rules.
ORIENTATION LOCK
Although the Kindle Publishing Guidelines state that the two available options for the "orientation-lock" metadata entry are either portrait or landscape, you can actually enter "none". This disables the lock and allows the content to reorient to the tablet's current position. This would seem most useful with reflowable content since, of course, with fixed layout the aspect ratio is set, and while the content will auto-zoom or shrink to fit the screen, it does so to the longest edge. This makes a page in portrait layout very small in landscape. However...
ZOOMING IMAGES
There are two alternate ways to insert images into KF8, as indicated in the samples provided for Children's Books and Comics. In the former a div element is created with an id that references the image source in the related css. In this mode the image is locked within the div block, and only content inserted into an overlaid region mag element can be zoomed. However, in the comic sample, the background image is simply referenced using standard html img src= tags. This allows for the region zooming feature which magnifies a specific area of the background image within a defined mag target frame. The magnification is actually created by restoring an oversized background image to its actual size (the image on the screen being shrunk to fit), with the frame acting as a window that lets you view only the selected area at full resolution.
But you don't have to create a window to do this at all. If you simply double-tap on an area of the background image that's not covered by a mag target tap zone, the entire image will "zoom" to the only window available: the Kindle Fire screen itself. Any text overlays will disappear, leaving only the selected image, with a circled X in the upper-right corner to facilitate exiting the zoom mode. While in this mode you can use pinch-and-zoom to view the image larger, rotate to either orientation (if the lock has been set to "none" as mentioned above), and drag the image around the screen with your finger. With the image size now upgraded to 800kb, this allows for images of relatively high quality at 1024x1748 - the width of the display screen in landscape orientation, and nearly three times the height. This seems a natural size for the full resolution image, since you can view full width in landscape and scroll up and down to see the rest of the image.
Unfortunately, the Fire is not as advanced as the iPad in having the cool "snap back" feature which keeps the image from being zoomed larger than the chosen viewport size. Still, this provides a way for the user to view and scroll the entire background image at a higher resolution without resorting to smaller cropped sections. Those, of course, can be added as well, so long as an obvious area remains where the background can be double-tapped (and the user knows the feature is available).
TEXT WRAPPING
My primary goal with KF8 fixed layout at the moment (and iBooks as well) is to create text that appears to wrap around images when in fact there is no text wrap feature available in the Kindle code other than around square boxes. To my mind the ability to wrap around complex objects is one of the fundamental advantages of Pages and the new iBooks Author drag-and-drop feature, and one for which I'm nearly will to cave in and buy a Mac. Still, there are ways around it in KF8.
While KF8 does not allow the use of left/right: #px; tags within mag target boxes, you can replace them with margin-left / margin-right tags instead, or text-indent for left indentations only. But in order to do so you will need to wrap each individual line of text in <p> tags and position them each separately. In the image to the right, for example, the first full paragraph is set to text-align: justify, but each line after that is a separate paragraph, positioned using either right-align (plus some word-spacing and/or letter-spacing to adjust the line width to my liking), or the default left alignment with an indent or left margin setting for just that line. This requires separate line entries in the css (i.e. p.line3 {...), each of which can then be individually manipulated.
This is somewhat tedious, to be sure, but the end result appears to be a text wrap function that does not, in fact, exist. In actuality, there is no image to wrap the text around, since the figure is simply part of the background.
TEXT SHADOWS
While KF8 (and iBooks as well) allow for text shadows in the css, they only allow for one. In other words, you cannot create complex, multi-color shadows using multiple, sequential text-shadow entries. Both KF8 and iBooks will only recognize and last entry given, which overrides any others entered above it. For my current project I required both a dark text shadow to offset the text against light areas of background color, as well as a glow layer to lighten darker areas behind the text. This was achieved by using multiple duplicated text layers on a z-index stack. The top layer has a fairly dark green drop shadow (1px 1px 3px #185244), while the bottom (otherwise identical) text layer provides a large light green surrounding glow, centered on the text rather than offset (0px 0px 40px #edffe7). I had already lightened up the text area somewhat in the background image itself, so not all of the lightening seen in the image above is from the text glow, but any stray dark areas are evened out somewhat and the text rendered more easily readable by its higher contrast with the background art.
ZOOMING TEXT
Below is a shot of my current Ring Saga project with the text zoomed in the Kindle Fire on the left and the same page seen in its full two-page spread on the iPad on the right. While you can retain the shape of wrapped text in the zoomed text box, you can also format the mag target separately, which I've done here, using fully justified text over a parchment backdrop. This gives the user the option of reading the text in something closer to a standard book layout, while also being able to view the art layout. Instructions for doing this are in the Guidelines, but I thought I'd offer an example of what I've done. It's certainly not as ideal as the iPad's ability to zoom fixed layouts to any size desired using pinch-and-zoom, but it's better than no option for enlarging text at all.
And while I'm on the subject of text, the function I'm most disappointed with in KF8 fixed layout is not having access to dictionary definitions by tapping words. Without that feature the purpose of embedding live text is virtually rendered null and void, particularly given that the search functionality is disabled as well. The only reason I can see for going to all the trouble of adding live text is in the hopes that Amazon will get its act together and fix these issues at some later date. For the time being, however, KF8 is little more than a PDF that's really frigging hard to make.
Sunday, February 19, 2012
Sunday, February 12, 2012
KF8 Graphic Novel Sample
There is now a KF8 graphic novel sample file available on Amazon's KF8 Overview page. This makes clear a number of questions posed by the somewhat sketchy graphic novel section in the Kindle Publishing Guidelines update. So if you're interested in how the Kindle Fire Panel View works, you can now open up the sample and have a look behind the scenes.
Among the things I've noticed is that metadata entries are included for both "comic" and "children" book-types, rather than one or the other. The "hybrid experience" mentioned in section 5.3.4 of the Guidelines does not state explicitly that both content types must be specified in order to create magnified text boxes in graphic novels, nor even that you can add both. Nor is the specific functionality of these two classifications anywhere clearly defined, but it is presumed the "comic" setting allows for image zoom, while "children" provides the text box magnification feature. However, a quick test in changing "children" to "comic" in my own KF8 version of The Ring Saga made no difference that I could ascertain, as text boxes still zoomed just the same.
Additionally, there are a few unique elements in the .opf's metadata section, most notably in two new zero reset functions:
There is also an enhanced doctype declaration in the html files:
Regardless, the sample provides much clearer examples as to how the Panel View region magnification functions, and how the larger resolution images can be used. The CSS in particular provides a wealth of information about how the mag regions are created and positioned, although at best it still seems an extremely tedious process of trial and error will be required to fine tune the zoomed image's location. Still, at least it's now possible to do, which is a start.
Among the things I've noticed is that metadata entries are included for both "comic" and "children" book-types, rather than one or the other. The "hybrid experience" mentioned in section 5.3.4 of the Guidelines does not state explicitly that both content types must be specified in order to create magnified text boxes in graphic novels, nor even that you can add both. Nor is the specific functionality of these two classifications anywhere clearly defined, but it is presumed the "comic" setting allows for image zoom, while "children" provides the text box magnification feature. However, a quick test in changing "children" to "comic" in my own KF8 version of The Ring Saga made no difference that I could ascertain, as text boxes still zoomed just the same.
Additionally, there are a few unique elements in the .opf's metadata section, most notably in two new zero reset functions:
<meta name="zero-gutter" content="true"/>Presumably these are designed to remove the default white space in the margins of the Kindle app, although their use is not included, nor explained, in the Publishing Guidelines, and I'm only guessing at the purpose of their inclusion. Certainly this is not required for fixed-layout content on the Fire.
<meta name="zero-margin" content="true"/>
There is also an enhanced doctype declaration in the html files:
SYSTEM "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"as well as the additional meta element:
meta http-equiv="Content-Type" content="text/html; charset=utf-8"Neither of these are present in the KF8 children's sample, but presumably they provide enhanced functionality not present in the 1999 standard but not yet finalized in HTML5.
Regardless, the sample provides much clearer examples as to how the Panel View region magnification functions, and how the larger resolution images can be used. The CSS in particular provides a wealth of information about how the mag regions are created and positioned, although at best it still seems an extremely tedious process of trial and error will be required to fine tune the zoomed image's location. Still, at least it's now possible to do, which is a start.
Labels:
eBooks,
Formatting,
KF8
Tuesday, February 7, 2012
DAZ Free Software Offer
DAZ Studio 4 Pro is the latest edition of the award winning 3D animation program which boasts some of the most leading edge advances in model manipulation and rendering, including the new Genesis figures that can morph into almost any shape or form imaginable. While you can buy the basic version of DAZ for a meager fifty bucks, the Pro edition normally retails for $430, and is well worth every penny for what you get. I've been using Poser for several years now (including the new Poser Pro 2012), but with the release of the Genesis figures I've been wanting badly to upgrade my plain vanilla DAZ to the Pro edition (and now I have!). Both programs are very similar, so if you know how to use Poser, you'll be able to dive right in to DAZ without any trouble. For those who've never used a 3D animation program, the learning curve can be quite steep (and tortuously unending), but in no time you'll be creating truly stunning works of art, even if you can't draw a stick figure to save your life. All of the art for The Ring Saga was created using 3D models.
Bryce is an environment creation tool, with the ability to produce utterly astounding digital worlds for your characters to populate. I honestly haven't used it much, as it's almost overwhelming in its possibilities, but if you want to build a fantastic backdrop for your 3D creations, this is the tool to use. Bryce Pro 7 retails at $250, so you can save yourself enough to buy a Kindle Fire and have some left over. The package comes with a ton of awesome content to get you started as well, from water planes to lush foliage, a multitude of terrain types, and a wide variety of skies.
Hexagon is a modeling tool for those who want to create their own 3D models instead of relying on the common stock of what's available to buy (which is a lot, by the way). I haven't done any modeling at all from scratch, so I'm looking forward to testing this program out. You can do a lot with morphs alone (my Alberich character was created entirely by morphing the crap out of a standard male figure model), but to create truly unique creations you really have to start from scratch and design your own. Plus, once you do you can sell them to others who don't want to bother! Hexagon 2.5 would set you package $150, but today it's free!
Click the image above to check it out.
Kindle Publishing Guide Updated
The new section covers how to create Panel View magnification targets to zoom selected sections of a page. As with the rest of the Guide, the details are sketchy at best, and the questions it leaves many. Unfortunately, Amazon has not provided a sample graphic novel to use as reference as they have for children's books and the standard KF8 format. Additionally, all the KF8 graphic novels that I've downloaded so far are DRM'd, so that I haven't been able to crack them open and look at their underlying code. I'm still having some issues getting absolute positioning to work correctly with text layers in the zoom regions, which is a bit frustrating to say the least.
Of primary importance, however, is the increase in the allowed size of image files to 800Kb in order to account for the necessary higher resolution graphics that are required. With zoom factors ranging up to 250%, recommended image resolution is as much as 1560x1500 pixels for a half page in landscape orientation, or 1536x900 for a full page image set to the default 150% zoom factor. This allows small print in fixed layout to be viewed at larger sizes, and artwork details to be viewed up close. In addition, the Panel View provides a "guided view" with the zoomed sections proceeding sequentially with each swipe.
Beyond allowing for zooming areas to view more detail, the benefit applies to full page images in general, as high quality art can now be added without having to use highly compressed jpegs that blur and distort details even at their default size. The down side, of course, is larger overall file size, effectively removing the 70% royalty option for graphic novels, since the bandwidth charge would likely be greater than the profit margin (see my post here for more on that). However, at the 35% royalty margin no bandwidth fee is assessed, so your ebook file can be a large as you like (within reason, of course: no one wants to fill up their Kindle with just one book).
Sunday, February 5, 2012
EPUB3: DOA
Barely more than a month ago, on January 1st, I made the prediction that the newly released ePub3 specification would "fail in its effort to heal ebook format fragmentation." This was, in fact, my number one prediction, and while it's hardly earth-shattering, it's happened faster than expected, and for the very reasons I outlined.
Less than two weeks into 2012 Amazon released the main specs for their new KF8 format, based mainly on ePub, but with a whole new set of a proprietary requirements for fixed layout features such as area magnification, and with severe restrictions on others such as image size and orientation. In addition, they use their own metadata entries to declare fixed layout properties. While KF8 is in essence an ePub in its structure, once converted into mobi via KindleGen it becomes proprietary and can only be read on a Kindle system. ePub files themselves are not recognized by Kindle devices.
Then, just a week later, Apple announced their new .ibooks format, along with the only tool that can be used to make it, iBooks Author. Again, the underlying structure is essentially an ePub, but with a host of new code elements that are entirely unique to Apple, with no relation whatsoever to anything in ePub. So complex and undefined are these new elements that there is no possibility of coding them by hand, so that what was once in essence an ePub is now something altogether different. And of course, it can only be read in Apple's iBooks system (and currently only on the iPad).
This is the direction things are going. As mentioned in my prediction, advances in technology and innovation in individual applications are far outpacing ePub's ability to keep up, to the point that very soon these formats will likely do away with the ePub structure altogether, since there's no inherent reason that they need it if the end goal is to produce a unique proprietary format. With KF8 you can at least begin with an ePub file and then modify it to meet the Kindle Fire requirements. But Apple has removed even that possibility. IBooks format files must be built from scratch, using their software, or not at all (and they must be sold via Apple's iBookstore, and consumed via Apple tablets).
Of course, Apple still accepts ePubs in their standard iBooks model (albeit with some custom modifications, such as the com.apple file), as does Barnes & Noble (though only for reflowable texts: BNKids format is so proprietary they won't even release the spec), but for fixed layout ebooks ePub3 has never really had a chance.
The idea of creating an open standard that many reading systems can handle is a noble, but unrealistic goal. It's just not a practical business model on which to build an empire. Success at the level at which Apple and Amazon are competing is accomplished by creating brand identity and loyalty. This is how Apple has sustained itself for many years, and how the Kindle became the first successful ebook reader. Certainly there are many other factors, among which producing a quality product is foremost. But to create a product of quality one must first create a product that stands apart from the others, and that by its very definition is a proprietary product.
While we will likely never see a major ePub3 reader, the market will be swamped with generic devices and off-brands that will do the job. But none of them will be truly great, relegating ePub3 to the sidelines and the cheap or free titles. Because of this it is unlikely ePub3 will ever reach its full potential.
Less than two weeks into 2012 Amazon released the main specs for their new KF8 format, based mainly on ePub, but with a whole new set of a proprietary requirements for fixed layout features such as area magnification, and with severe restrictions on others such as image size and orientation. In addition, they use their own metadata entries to declare fixed layout properties. While KF8 is in essence an ePub in its structure, once converted into mobi via KindleGen it becomes proprietary and can only be read on a Kindle system. ePub files themselves are not recognized by Kindle devices.
Then, just a week later, Apple announced their new .ibooks format, along with the only tool that can be used to make it, iBooks Author. Again, the underlying structure is essentially an ePub, but with a host of new code elements that are entirely unique to Apple, with no relation whatsoever to anything in ePub. So complex and undefined are these new elements that there is no possibility of coding them by hand, so that what was once in essence an ePub is now something altogether different. And of course, it can only be read in Apple's iBooks system (and currently only on the iPad).
This is the direction things are going. As mentioned in my prediction, advances in technology and innovation in individual applications are far outpacing ePub's ability to keep up, to the point that very soon these formats will likely do away with the ePub structure altogether, since there's no inherent reason that they need it if the end goal is to produce a unique proprietary format. With KF8 you can at least begin with an ePub file and then modify it to meet the Kindle Fire requirements. But Apple has removed even that possibility. IBooks format files must be built from scratch, using their software, or not at all (and they must be sold via Apple's iBookstore, and consumed via Apple tablets).
Of course, Apple still accepts ePubs in their standard iBooks model (albeit with some custom modifications, such as the com.apple file), as does Barnes & Noble (though only for reflowable texts: BNKids format is so proprietary they won't even release the spec), but for fixed layout ebooks ePub3 has never really had a chance.
The idea of creating an open standard that many reading systems can handle is a noble, but unrealistic goal. It's just not a practical business model on which to build an empire. Success at the level at which Apple and Amazon are competing is accomplished by creating brand identity and loyalty. This is how Apple has sustained itself for many years, and how the Kindle became the first successful ebook reader. Certainly there are many other factors, among which producing a quality product is foremost. But to create a product of quality one must first create a product that stands apart from the others, and that by its very definition is a proprietary product.
While we will likely never see a major ePub3 reader, the market will be swamped with generic devices and off-brands that will do the job. But none of them will be truly great, relegating ePub3 to the sidelines and the cheap or free titles. Because of this it is unlikely ePub3 will ever reach its full potential.
Subscribe to:
Posts (Atom)






