Saturday, March 31, 2012

Amazon's Free Prime Promotion

In appreciation of that finest and funnest of all holiday observations - April Fool's Day - when you can give your boss a dirty sock with a wry smile and virtual impunity - I'm offering up my debut novel at the absurdly low low price of absolutely nothing whatsoever. From now until Saturday at midnight you can download The Saga of Beowulf (Complete Edition) for free. No fooling!

I haven't talked about the Amazon Prime program much, aside from an initial look at the Prime Lending Program back in January, when it proved quite a success. February, for the record, was even better for authors enrolled in the Kindle Owners' Lending Library that the previous two months, when per-loan revenue payed out at $2.01, up from December's initial take of $1.70 and January's slightly lower $1.60 per title borrowed.

This is impressive and somewhat startling given that the number of titles sharing that pool has increased dramatically in the interim: Amazon reported at the end of February that titles enrolled in the Kindle Lending Library had reached 100,000, twenty times more than the program started with back in November. More importantly, and to the point here, better than a third of of the Top 20 Kindle books last month were enrolled in the program, with average increased sales of 24%, lending weight to the value of the program for both authors and readers alike (at least readers with a Kindle, that is).

I can vouch for this myself, as I've experienced the same effect. However, it's difficult, if not impossible, to determine just how much the increase in sales is due to enrollment in the lending program - with its increased visibility via promotions both on Amazon and sites like Kindle Nation Daily - or to the rapid rise in Kindle device ownership since the program started: I noted in my prior post that January's device sales literally doubled the ownership of both dedicated e-readers and tablets among U.S. adults.

That said, there is another aspect to enrollment in the Kindle Lending program that is relevant to my own promotion today. With each three-month enrollment period come five free days of promotion, when you can give your title away... well... for free. I didn't take advantage of this during my first three months, wanting to observe how the period played out on its own, but also being somewhat uncertain how much good giving away a book for free would actually be. After all, that's five days when you're not selling your ebook anywhere, since the program requires exclusivity to Amazon in order to enroll - meaning that Amazon now has 100,000 ebook titles on their shelves that no one else can sell (the exclusivity agreement applies only to ebooks, by the way, not to print editions of the same titles). As I mentioned previously, I've gotten around this myself by having the two-volume edition on sale elsewhere, so I'm not losing out entirely as others are. Still, since nearly all of my sales are via Amazon, I wouldn't be losing much anyway, and it's more than made up for by the increase in Kindle sales.

Odd as it may seem, my sales actually increased after my first "free" promotion last month, which ran for two days. During the promotion The Saga of Beowulf hit number 1 on the Top 100 Free ebooks in both the U.K. and Germany, and #2 in France, while peaking out at #36 here in the States. I gave away just under 2000 copies in two days and got a lot of free promotion, some new reviews, and (one can only hope) a broader fan base. But the real surprise came in the subsequent weeks, when the title continued to hover in the upper thousands range in the overall ranking for Kindle ebook sales, rather than it's usual location down around 20,000 or so.

As you can see from this screenshot, I hit #4,745 at one point, which was pretty much as high as it got in the U.S., while the U.K. saw a spot in the top 2000. This equates to an average of roughly 7-8 sales per day, give or take, peaking at something like 10 sales in a single day, during the entire month of March, without slowing, since the promo ended, for a total of just over 200 copies sold this month, which is about a 30% increase in my average. This is almost certainly due to Amazon's own promotion of the title, via spots on the "You Might Also Like..." and "Customers Also Bought..." sections. All those free downloads have linked my book to other titles that those customers also bought (or got for free), so that it now shows up more often in those spots. I come up under books by Bernard Cornwell, for example, which is a nice boost in visibility aimed directly at an audience that likes this type of stuff.

I mention this for the sake of other independent authors enrolled in, or thinking of enrolling in, the Kindle Owner's Lending Library program. You'll have to decide for yourself where to focus your sales efforts and if the exclusivity requirement is acceptable or not. But at least you now have a bit more information based on solid sales data, which in the end is what you want. Just remember that sales = readers, and readers are what an author wants. In the end it doesn't matter where you get them.

Friday, March 30, 2012

Of Missing Thumbnails & Disappearing Jackets

About a week ago a reader left a comment here that sent us both into a frenzy of activity, code spelunking like gold-drunk miners and treating our iPads far more harshly than is prudent. As you can see from the screen shot above there is a glitch in the iBooks preview scrubber that causes thumbnails in fixed layout ebooks to go missing.

Of course, we both assumed the fault was ours, as we were each looking at pages from our own fixed layout projects at the time. David B, the reader in question, was following my iBooks fixed layout tutorial when the issue arose, and the natural conclusion was that he had gone astray somewhere (and possibly that I had led him there). A flurry of comments and replies ensued, followed by longer emails and photo exchanges as we sought to narrow down the possibilities and rule out each element or potential error.

But this wasn't the only error occurring. David had discovered that if you read through a fixed layout iBook and then go back to the beginning, the cover disappears. He was able to make this happen not only for the front cover, but the rear one as well. He sent me his ebook and he downloaded mine. I tested both on my new iPad and my iPad 2 (he only has the new one), and discovered that the break occurs even easier on the older model than the new one. So more code was torn apart and analyzed, the cover tags and references poured over, and the image size and format considered, until there was literally nothing left to look at. We were stymied.

This is when I started to wonder whether it was in the code at all. Probably I should have done this sooner and saved us both a lot of headache (which is the point of this post), but I loaded in the Game of Thrones graphic novel shown above, and as you can see the same thing happened. After only a few scrubs back and forth the thumbnails turned to black and the covers went away. I should mention here that the thumbnails and images all load in just fine at first, so if you're reading like a normal human being and not a manic ebook builder you'll likely never notice this. In fact, this is an inconsistent problem to some degree, which does not always affect the same pages, either in different books or the same book on different devices - or even on separate viewings of the same ebook - although the same pages do tend to break more often, while others do not. For example, in David's picture book he had only two thumbnails go blank consistently while I had all but two go black on the first viewing, and then none at all the second time, even though I roughed it up by playing on the scrubber bar like Mozart on a drunk. Conversely, I could never get his cover images to disappear, although not only does the Game of Thrones cover go missing on both my iPads, but the inner cover does as well.

Given that a professionally produced ebook such as A Game of Thrones is showing the same symptoms as our own, this is clearly a glitch in the software and not the ebooks themselves. The current version of iBooks (2.1) was updated on March 7th during the launch of the new iPad, just a week or so before David first noticed the error (the leap to Version 2.0 having happened back in mid-January with the advent of iBooks Author and the new .ibooks format). But I had never noticed this glitch before he pointed it out, even though I've loaded and reloaded my project file well over two hundred times in the past few months, scouring back and forth through every page a dozen times or more with every new revision. One would think I might have noticed something as obvious as this if it had been occurring prior to the latest update. But I had finalized my sample chapter well before March 7th and hadn't looked at it again. That is, until last week.

So this is just a notice to others working on fixed layout iBooks not to freak out and waste a lot of time fretting over something that can't be fixed. I've dropped line to Apple support and left a message in the forum to make sure others are aware of this. Hopefully it will be dealt with in the next update, and hopefully it will be soon.

Thursday, March 29, 2012

Children's eBook Sales Up 475%

According to the latest figures from the AAP, January was a banner month for illustrated ebooks geared toward a younger audience. While the post-holiday season was good to digital content in general, the Children's/YA category saw a whopping 475.1% increase over the same month last year, from $3.9 million in January 2011 to $22.6 this year.

And for the first time in quite a while, print sales for the category increased as well, by 61.9% for paperbacks and 68.9% for hardback books. Even Adult print sales showed improvement after a lethargic year, rising by 21.6% for hardcover titles and a modest 6.1% for Trade Paperbacks. Unfortunately, the much shunned Mass Market Paperback sector did not fare as well, seeing yet another double-digit decline, this time by -22.5%. Overall, however, total trade sales saw their first significant increase in at least a year, growing by an impressive 27.1% over last January, with Adult Trade seeing a 16.4% improvement overall and Children/YA gaining 80.5% in all segments combined.

These stats, it should be noted, represent the most comprehensive and accurate reporting by the AAP thus far, with a greatly increased number of publishers participating, from fewer than a hundred last year to 1149 for this report, all of whom provided year-over-year sales data. In addition, for the first time eBook sales are broken out for Religious titles and the Children's/YA categories. Figures for Religious sales have been lumped into one subcategory until now, so that it was unknown how much ebooks were accounting for their generally impressive sales over the past year. The new report shows Digital with a 150.7% increase, while Hardcovers showed only a 2.9% increase and Paperbacks were down by 10.3%, the implication being that ebooks have driven Religious sales for quite some time.

This massive leap in digital children's content can be attributed to several factors that, combined, can tell us much about the current state of digital affairs. Firstly, since a large percentage of children's and young adult titles are heavily illustrated, they have been dependent on improvements in fixed layout formats that have made significant advances in the past year. Amazon's launch of the Kindle Fire in November, for example, opened up a whole new market for digital comics and graphic novels with its new KF8 fixed layout format and full color screen - just in time for the holidays. Additionally, Barnes & Noble's Nook Kids (Digital Replica Plus) format launched with 12,000 titles just over a year ago when the Nook Color was announced in October 2010, with the iPad app following in January of last year. And, of course, it was the iPad itself that opened up the field to fixed layout content in the first place via apps and, in December 2010, iBooks 1.2 which brought support for fixed layout ePubs to the iPad's native reader. Consequently, this past year has seen a rapid influx of new graphic novels and children's classics brought to life in digital for the first time as trade publishers have at last embraced the format and worked out how to get complex content like comics and picture books formatted for these new platforms.

Secondly, the rapid decline in the retail cost for entry level e-reading devices last year, combined with an increase in availability and options, led to what can only be deemed a tablet boom this past January when, according to recent Pew Research survey results, device ownership nearly doubled in a single month, from 10% of adults to 19% - for both e-book readers and tablets. One can only surmise the vast majority of these were Kindles purchased as gifts at their newly lowered price point, and from reported estimates, some five million Kindle Fires. These new sales figures also tell me that a great many of those devices purchased over the holidays were at least in part intended to be used for entertaining and educating children, something not even possible a year ago for a large part of the current market.

In a related report, Bowker's recent Global eBook Monitor study showed that 20% of respondents from ten countries had purchased an ebook in the previous six months, with vastly more planning to do so in the next six months. Worldwide, 80% of adults are aware that electronic books can be downloaded, which is significant in that it shows a growing global market primed for a product that can be made available instantly and anywhere as soon as the infrastructure is in place. Amazon, for example, rolled out the WiFi Kindle Touch to over 175 countries last month, with the 3G model set to launch on April 27th. And just last Friday the new iPad went on sale in 25 countries across the globe. Expect to see sales of ebooks continue to boom in the coming months.

Monday, March 19, 2012

KF8 Fixed Layout Image Zoom Tutorial

KF8 "Panel View" Zoom
In this installment I'll show you how to zoom images in KF8 fixed layout ebooks using a few important variations on the code used to create text mag targets (discussed in the first part here), as well as how to add a lightbox effect to dim the background surrounding the magnified area (as seen in the image on the left), and within the magnified region itself as a semi-transparent fill. In addition, I'll discuss the elements that allow you to include live text overlays on top of both the full screen and zoomed images.

The easiest way to explain how these features work is to go through an example step by step. Thus, it will be helpful if you have downloaded my template and can view the examples given there, as I'll be using the code for Page 3 here to describe the relevant elements and their variables. Both the converted .mobi and the original source .epub are available from links in my earlier post here (updated 3-28-12).

The primary difference between text and image zooming is that with text the content is entirely contained within the magnified area, and in part determines how large the target container is. Conversely, with image zoom the mag region acts as a window through which you can see a portion of a larger, hidden image underneath. First we'll examine image zoom with live text overlays, and then we'll look at how to use a lightbox to create a semi-opaque fill.


1 <div class="fs">
2 3 <div> 4   <img src="../images/Image.jpg" alt="Description" class="image"/>
5 </div> 6 7 <div class="note"> 8   <h1>Non-Magnified Text</h1>
9 </div> 10 11 <div id="zoom1"> 12   <a class="app-amzn-magnify" 
13     data-app-amzn-magnify=
14     '{"targetId":"zoom1-magTargetParent", 
15     "ordinal":4}'>
16   </a>
17   <div class="center">
18     <p>Double-Tap Here To Zoom</p>
19   </div>
20 </div>
22 <div id="zoom1-magTargetParent" class="target-mag-parent"> 23   <div class="target-mag-lb"></div>
24     <div id="zoom1-magTarget" class="target-mag">
25     <p class="textzoom">Zoomed Text Overlay</p>
26     <img src="../images/Image.jpg" alt="Description" />
27   </div>
28 </div>
29 30 </div>

This is the Page 3 code before I inserted the lightbox fill addition, which I'll define and explain separately below. I've numbered the lines here to facilitate the following discussion: they're not part of the code, and the numbering you see in your file editor of choice will be relative to their position in the full page of code. In the actual template they are extracted from they span lines 14-41, for example.

As you can see, there are four subdivisions within the overarching div container. I've used fs, by the way, for the fullscreen div container spanning lines 1-30 simply because this is Amazon's default in the provided samples, and it's as good as any; but you can name it whatever you like, so long as it matches its reference in the CSS. As with the text example discussed in the first part of this tutorial, this overarching container defines the overall size of the page, and holds all the content to be displayed (hence, fs for full-screen).

DIV 1: LINES 3-5

In order for the image magnification to function you must use the img src= insertion method for your background image, as opposed to the div id method used on the contents page example in the template (and all the page layouts in Amazon's children's ebook sample). The CSS class "image" is set to use absolute positioning with a height and width equal to the full display size. The image will shrink to fit the screen while retaining its default aspect ratio. Using this insertion method, the user can double-tap the background image at any point that is not covered by a mag region, and use pinch-and-zoom to enlarge the full image to any size they desire. This is not possible with the div id insertion method, which locks the image within the div container.

This image should fill the entire page, although this does not necessarily have to be the entire display: the image above, for example, is how a standard 6x9 print book page displays on the Kindle Fire: the widescreen aspect ratio of the Fire's display leaves white space at the top and bottom. My solution to this was to add decorative borders above and below the page (see example here), but of course this isn't necessary, and your pages may be any size and shape you like, such as square or wider than high for viewing in landscape mode.

The image you insert as the background must also be embedded at the highest resolution you want it to be zoomed to. So, for example, if you want the zoomed regions to be magnified by 150%, then this image needs to be 150% larger than it will appear when shrunk to fit the Kindle Fire screen. For a full screen image this would be 1536x900 pixels (1024x600 times 1.5). The pixels per inch, by the way, does not matter: 72 ppi will display the same as 300 ppi on the screen, since it's the number of pixels that determines its dimensions relative to the display size.

DIV 2: LINES 7-9

This div element contains any text you don't want to include in the magnified region. Here it's a simple header, but you can of course include whatever elements you like, either in a single div, or in multiple containers as needed (or none at all). Since we're using absolute positioning, these containers can overlap one another without affecting the positioning of those above or below, so long as the Tap Targets are on top (i.e. added last in the HTML code). This text can also be live if you follow my instructions given in the earlier post.

The div class references the CSS positioning data for the container, which is aligned to its top and left edges, with the width parameter used to define the right margin. So, for example, a left position of 10% combined with a width of 80% creates an equivalent right margin of 10%. A left position of 0% with a width value of 100% leaves no right margin at all, and fills the screen from edge to edge exactly. The height of the text container is determined by the content itself.

DIV 3: LINES 11-20

So now we get to the crux of the matter. This div container creates the Tap Target Zone: the area within which a double-tap activates the zoom of that region. The size and position of the Target Zone is defined by the div class values provided in the CSS:

      #zoom1 {
            top: 30%;
            left: 15%;
            height: 45%;
            width: 70%;

Here the top edge of the tap zone begins 30% down from the top, 15% in from the left, extends downward a further 45% of the display height, and 70% of its width - leaving 15% on the right and 25% on the bottom not covered by the tap zone. As I mentioned in my prior post on live text, one of the benefits of activating live text by deleting the book-type metadata entry is that it causes the Tap Target Zone to appear as a gray box when touched, allowing you to see exactly where the target boundaries are. Even if you do not intend to use live text in your final product (although I can't imagine why), it will help you to position your target element here.

Within this div container is the JSON object already discussed in the first part of this tutorial. The only differences here are that the SourceId is not used (for reasons to be given shortly), and the targetId references a magTargetParent rather than the magTarget itself. We'll get to the specifics of that in a minute, but essentially this creates a link that points to the magnified element defined in the next section.

You may also notice that the CSS contains a set of values for the anchor tag (div.fs a). These define the JSON hyperlink as a block (or "Tap Target Zone") covering 100% of the div container that holds it, in both height and width, so that double-tapping anywhere within this region activates the link.


Normally (as far as Amazon's description is concerned, at any rate), the JSON object is all you would include in this container. However, you can include some live text here as well if you like by embedding a second div container within the first. Here I've included some instructions for the reader so they know that the region can be magnified. You might use this to add live text to a dialogue balloon in a graphic novel, for example, instead of including it in the image itself (which is not an optimal solution, for reasons I've discussed at length in other posts).

As before, the div class here references the CSS positioning data for the text container, while the content itself is formatted using header/paragraph tags as usual. This text can be as simple or complex as you like, using any HTML/CSS elements supported by KF8 (see the end section of the Guidelines or the KF8 detail page here for a list of accepted tags and their variables).

Bear in mind, however, that this text will not actually be magnified. Unlike the standard "children" ebook method of zooming text, which allows you to magnify the default text by using the SourceId tag, here we have to fudge the rules a little to make this work, as you'll see in the next section. Additionally, this text will not disappear as it does in the standard text zoom method unless you enclose it within the anchor tags, which I haven't done here simply for the sake of clarity in keeping the two components of this section separate (and, of course, since you'll be covering it up with an enlarged image region, it won't matter anyway).

DIV 4: LINES 22-28

Our final container holds the data that defines the magnified region itself, and here is where things get a little tricky. The div id value must equal the targetId from the JSON object, as this is the target that link is referencing. The class value defines the "parent" element, which is simply a container to enclose a number of distinct constituent elements. The parent is required here in order to create the lightbox effect, since the lightbox needs an opacity value that applies only to it, and not the zoomed content itself. If you don't intend to use a lightbox you can use a standard magTarget here and do away with the parent altogether, as I've done on Page 4 of the template.

You will notice that the only values applied to the target-mag-parent element in the stylesheet are a width and height of 100%, and a display value of none. The former simply makes the parent large enough to contain everything you put inside it and no larger, and the latter keeps it invisible until it's activated. Also, if you delete the lightbox element as mentioned in the previous paragraph, be sure to include the display: none entity in the magTarget CSS so that the magnified element is not visible until activated. Otherwise, it will appear by default, and disappear when double-tapped (which, by the way, might be good to know if you want something hidden underneath a larger image to appear, as might be useful in children's books).

This parent div container holds two individual sub-containers, the first being our lightbox element and the second one containing the magnified content itself.

Line 23 inserts the lightbox, which is defined in the CSS by the target-mag-lb values. Like the parent element itself, the target-mag-lb values define the lightbox as covering 100% of the width and height of its content. But since the only content in the lightbox is a background fill color without any defined size parameters of its own, the lightbox defaults to the overall dimensions of the display screen, thus filling the entire page with color. The color used in Amazon's examples is a dark shade of gray, which I've retained as it seems a natural choice for dimming out an image, but of course you can use any color that you like. The opacity value determines how much this fill obscures the background image.

Now at last we come to the magnified content itself. This is held within the second sub-container, whose id value defines its size and position:

      #zoom1-magTarget {
            top: 21%;
            left: 0%;
            height: 62%;
            width: 100%;

And whose class defines some values for its content: {
            position: absolute;
            overflow: hidden;
            border: 5px solid  #000000;

We'll get to size and position in a minute, as this is a rather tangled affair, but first let's dispense with some other factors. The target-mag values here are only part of the picture, as there are several sub-components entered separately. However, these provide some overall values that define how the magTarget functions...

First, it will use absolute positioning to make it easier to place exactly where we want it. The overflow value keeps the portions of the image not visible within the window hidden. And finally, we'll add a nice little border around the whole to make it stand out better. You can also use the border-radius tag to round the edges if you like, or any other decorative frills you care to add, so long as they're supported. This, incidentally, is how you might create circular magTargets for use as callout boxes or dialogue balloons: by adding a high border-radius value and a white background fill under centered text, your magnified target would look like a dialogue bubble, albeit without the pointed indicator.

In this example I've added a bit of text to overlay atop the magnified image, and this requires a bit of explanation. Since we can't use the SourceId tag to magnify the actual text on the page (since that source does not include the magnified image we also want), we must enter the alternate text here. Consequently, this can be the exact same text or something altogether different, as it is here.

      p.textzoom {
            font-size: 150%;
            margin: 20%;
            top: 18%;
            z-index: 1;

I've used a separate paragraph class to define the values of the magnified text that vary from the default text, foremost of which is that it be 150% larger. The next two lines position the text where I want it in the magnified target, and the final one is what allows the text to be overlaid on top of the image rather than being forced below. Since the default z-index value is "0" any larger number will place that element higher in the vertical stack. Bear in mind that the positioning information here is relative to the magTarget boundaries, because my default paragraph has a relative position value. This actually makes it easier to position elements within the enlarged region, since it's easier to visualize their position with regard to their immediate surroundings.

Finally we come to the image itself, which is added as before using the img src= insertion method, minus the class tag. Here we're referencing the same image as the one above, but this isn't strictly necessary. You could, in fact, use this to create images that change when double-tapped, such as a facial expression or an opened door. In that case you might create an image of the same size but with different content that the double-tap or swipe would trigger. You might, in fact, have a series of events all strung together, each one triggered by sequential swipes. But I'm letting my imagination get away from me... let's get back to the matter at hand.

In the stylesheet there are a number of additional entries for the element, but with the img entity appended. The first of these defines the actual image resolution: img {
            position: absolute;
            height: 1536px;
            width: 900px;

These are the actual dimensions of the image you've included in your file, and this entry tells the device that the image contained within the target-mag is 1536x900 pixels in size. The following entries provide values for that image various magnifications by appending a zoom factor: img.zoom100 {
            position: absolute;
            height: 1024px;
            width: 600px;
      } img.zoom150 {
            position: absolute;
            height: 1536px;
            width: 900px;

The first of these defines the default display size, and will be the size of your page rather than the screen size; that is, as discussed earlier, whatever size your page is when fitted to the Kindle Fire screen, which may or may not be the full display resolution if the aspect ratio doesn't match. Here I'm using an image that is formatted to fit the Fire display precisely.

The second entry defines the size of that image magnified by 150%, which in this example is our default zoom factor. However, you can include as many variations on this as you wish, but to do so you will also need to include a class tag to your img src= entry in the HTML, as such:

      <img class="zoom150" src="...

In this way you can magnify various panels at different zoom levels, providing your image is embedded at the size that magnification factor requires. If you only use one zoom factor throughout your book you can leave this class tag out.

One more thing should be mentioned. While the Kindle Publishing Guidelines expressly state that there are four standard zoom factors, you can in fact use any magnification level you choose. The zoom### tag is just a reference that tells the device to display the image at that size, rather than shrinking it to fit the display. But I've used other magnification factors and they work just fine. The number given after zoom doesn't even have to be the actual zoom factor used (although using another number would likely prove confusing); it's the values entered for the height and width that matter.

So now that we have our content added we need to work out how to size and position it...


Determining the size and placement of the magTarget window can be a matter of considerable frustration, but a little simple math can go a long way toward alleviating these headaches. Let's say that your image is like the one in the picture shown above, and you want your first magTarget to appear in the upper left corner at 150% of the display size. First you must determine how large the panel to be enlarged is, and the easiest way to do this is to open your full-page image in a graphics program such as Photoshop or GIMP. Using the rulers set to show percent, you first measure the width and height of the section to be magnified, and then multiply those dimensions by the amount of magnification to achieve your window size.

So, for example, an image section 42% wide by 35% high in the original intended to be viewed at 150% when zoomed would require a magTarget 63% by 52.5% in size. These values are entered in the stylesheet in the #name-magTarget entry (where name is the specific tag reference for that entity). Using percentages, by the way, removes the necessity of calculating pixels to percents, and "future proofs" the layout against changes in display resolution by using relative values rather than absolute ones, theoretically requiring only the change of the absolute height/width display values and replacing the actual images with higher resolution ones. I haven't been quite as consistent as I should in using percents instead of pixels myself, however.

Bear in mind, of course, that the amount of magnification determines the maximum size of an image section that can be zoomed. Thus, for an image you want to zoom by 200%, 50% x 50% is the largest section of a full page image you can isolate within a window, which in that case would be a window 100%x100% in size, covering the entire display with the enlarged section of the image. At 150%, a width and height of 66.6% would achieve the same result.

Positioning the window on the page works much the same way, although in most cases, given the larger size of the magnified region, you'll want to align it to one or more of the edges, such as left: 0% in the example given above. The width: 100% value fills the screen horizontally, while the top: 21% and height: 62% values place the image near the middle of the page vertically, with a 17% margin remaining on the bottom.

Of course, if isn't quite as simple as that once you move away from the upper left-hand corner. Since the full size image is much larger than the display screen, much of it will fall beyond the edges, beyond the reach of the window. Thus, we need another entry in the stylesheet:

      #zoom1-magTarget img {
            top: -77%;
            left: -25%;

The image by default is positioned in the upper left-hand corner, with the overflow going off the right and bottom of the screen. Therefore, in order to view those sections of the enlarged image we need to move it up and left until the section we want to view is visible within the window. Now, if you thought you had a headache before, you're in for a real treat now.

The crucial factor here is that all values are in percentages of the magTarget size, not the actual image size, nor the display size (unless, of course, your window size is the same as the display). Thus, you need to work out how far you need to move the image, and convert that to percentages of the window you've created to view the magnified panel.

For example, let's say you have an image that is 1200 pixels wide by 2048 pixels high: that is, exactly four times the size of the Kindle Fire screen, with a window size the same width as the display (600px), but only half its height (512px), aligned to the bottom of the screen. This might be a common configuration to view a panel in the lower-right corner, for example, zoomed to fill the bottom portion of the screen.

Since the actual image by default is placed flush against the top and left of the screen, you'll need to move the image 600 pixels to the left and 1024 pixels up from its default position in order to view the lower-right quarter in a window at the bottom of the screen. Your values would therefore be left: -100% and top:-200%. That is to say, you need to move the image 100% of the width of the magTarget size (600px), and twice its height (512px x2 =1024px). It's easiest if you always place your window flush against at least one edge of the display, and preferably a corner, leaving the other two sides for adjusting the window size to fit the given panel.

Of course, it's rarely that easy, since you also need to take the window position into account, as well as any margins surrounding it if it's centered or only flush against one edge. And, of course, you've defined your magTarget window using percents not pixels, so there's a little math involved there, too. But using this same formula you can work out fairly quickly just how far you need to move the image to get it roughly where you need it. A little tweaking once it's more or less in place will ultimately get it where you want it.


As promised in my last post, I'm adding this addendum describing the modifications required to include a transparent background fill for your mag targets that leaves the text fully opaque. You'll need to create your default content using a parent element as we did in the example above. This allows us to include two separate div containers in the magTarget that enclose the lightbox and the text within separate entities so that they can be formatted individually.

Here's my HTML for the added content on Page 3 of the template:

     <div id="zoom2">
            <a class="app-amzn-magnify" data-app-amzn-magnify=
            '{"targetId":"zoom2-magTargetParent", "ordinal":5}'>
                  <p class="note2">Default Content Here</p>

      <div id="zoom2-magTargetParent" class="target-mag2-parent">
            <div class="target-mag2-lb"></div>
            <div id="zoom2-magTarget" class="target-mag2">
                  <p>Magnified Text</p>

When inserting your default content in the main div container be sure to enclose it within the anchor tag for the JSON object so that the default text will disappear when the magnified region appears. Otherwise you'll see the default content through the transparent fill. But anything contained within the JSON link will disappear. You can format this content however you like, with one caveat: for some strange reason it appears you must insert this content directly between the anchor tags, without any intervening div containers. Otherwise the link will not be active. I have some theories about this, but no time to test them right now (that is, if this tutorial is ever to be finished). I'll update the post when I work it out. [SEE UPDATE BELOW!]

For the target content you'll format the parent element the same as before, with a height and width of 100% and a display value of none to make it hidden by default. Within this you want to create a div element for your lightbox, and another for your magnified content. It's easier to fill the background after you know how large the magTarget will be, so let's format that content first:

      #zoom2-magTarget {
            top: 75%;
            left: 0%;
            display: block;
      } {
            position: absolute;
            display: none;
            font-size: 150%;
            padding: 15px;
            border: 5px solid #000000;
            background-color: none;

First, use the div id values to size and position your magnified region. Here I've positioned it three quarters of the way down the screen and aligned it to the left edge. I haven't defined a width or height, as these will be determined by the magnified text, which in this case will fill the full width of the screen and create a box tall enough to fit it all. You can, of course, define a width less than that of the display, as I did in the first magTarget example on this page.

The class tag values are where you format the appearance of the magTarget. Unlike the image zoom example, here is where you define the zoom factor for the text content, which in this case has a magnification value of 150%. Adding a percent here allows you to multiply the default formatting by a consistent factor, rather than trying to calculate the larger pixel value. The other important change here is to set the background-color to none (or just leave it out). This creates a fully transparent container with just the content visible.

Now that you have your magnified region active and visible you can format the lightbox to fill it in. Of course, you want the fill to be inside the magnified region rather than outside it, so you'll need to change the size and position values to match the text container. Your top and left position values will be the same as the text container itself, so just copy those. The width you've also either set or left unspecified as I have, in which case it equals 100%. But the height is a little trickier, since the text itself determines that value. You'll just have to use some educated guesswork to get it close and adjust until you get it right. {
            top: 75%;
            left: 0%;
            height: 18.5%;
            width: 100%;
            background-color: #FFFFFF;
            opacity: .3;

The fill itself is provided by the background-color value - here set to white - and an opacity that determines how transparent or opaque that color is, in a value ranging from 0 to 1, where 0 is invisible and 1 is completely opaque. You can enter the color value as a hexadecimal code as I have here, or as RGB, or simply by using names for basic colors, such as black and white. White seems the logical choice, as it appears to lighten and desaturate the underlying full page image, making the text easier to read by standing out in higher contrast against the lightened backdrop.

Here, by the way, you don't need to use a z-index to stack the text on top of the color fill as you did with the magnified image, since the background-color element is placed at the bottom by default.

That's about all I can tell you for right now, although I'm sure there much more to it than that, and more than you can do. Just use your imagination and the possibilities are likely endless. Best of luck, and let me know what you come up with.


So this is one of those really stupid things you do when you're tired and have been staring blindly at code for days on end. I finally found some time this  morning to have a look at the div issue mentioned above, in which it appeared as if you had to insert text directly between the JSON anchors. This, as I suspected, is not the case. You can, in fact, add anything you like within the anchors and it will disappear when the link is activated.

What was precluding it from doing so in my semi-transparent fill example was the absence of a height value for the root container ("zoom2"), so that my TapTarget had width and correct positioning, but no height, and thus was inaccessible (though technically present). I had somehow neglected to add this in the latter example, even though it's in the main example above ("zoom1"). This was likely due to the fact that text itself determines the height of its container. But, of course, it does not do so for the parent container which contains that container. That height you have to set yourself. Also, be sure you add the following to your css:

      div.fs a {
            display: block;
            width : 100%;
            height: 100%;

This will tell the JSON object to fill the space you've just provided with an active link. My apologies for the confusion. I didn't mention that specifically in the tutorial, although it's in the template, so I thought I'd mention it here just in case. My apologies for any confusion.


The definitive guide to the Kindle fixed layout format, this fully revised and expanded tutorial will take you line-by-line through two working templates, including both the content and support files, as well as all layout and functionality features, explaining in painstaking detail what each element is for, and what your options are in every instance. Also included in the ebook is a code to download both templates for free!
Add to Cart
$9.99 [8.94 Mb]
Kindle reflowable .mobi format

Sunday, March 18, 2012

KF8 FL Template Updated - Again!

As I mentioned way back in my first post of the KF8 Fixed Layout template, I had wanted to create a text box with a semi-transparent background fill, but left it out due to the fact that the opacity value in the CSS magTarget entity applies to all content included in the mag region, text included. Thus, as presented by Amazon, there is no real use at all for the opacity tag.

However, as I postulated previously, it should be possible to create a lightbox that is sized so as to be contained entirely within the magnified region, rather than without. As you can see by the image at the left, I have done just that. The newly yet-again once more updated template now includes an example of this usage on Page 3, along with the standard lightbox style.

My primary reason for wanting to include this feature is that it allows the magnified text box to include a background texture that exactly matches the actual content on the page, while being completely readable, as opposed to an opaque fill or inserted image that at best can only approximate the page content, and only if you embed a different background image for each and every page (or have pages that vary only slightly in hue and tone); the only other option is to use something highly contrasting and not bother color matching at all, such as a plain white fill. Initially I inserted a parchment backdrop behind my zoomed text, but I found that too distracting for my taste, and wanted something more subdued and subtle. I also tried a slightly desaturated image of the background texture sans text, but this was not entirely satisfactory, as it increased the overall file size unnecessarily by requiring multiple versions of every background image. This is the solution I was after.

You can download the latest update of the .epub and .mobi files from the post linked to above, and view the code to see how this was done. It's not the cleanest code I've ever seen, mind you, and I'm sure I could have organized the stylesheet better, but what's necessary is all in there. I'll probably refine it a bit later. The new code is for the most part added to the bottom and kept together, rather than intermingling it with the rest, so as not to be any more confusing than need be. I'm nearly done with the image zoom portion of the KF8 fixed layout tutorial, and hope to post it later today if all goes well. Of course, I now have to add a new section to it in which I explain the elements of this new functionality. After this I'm swearing off any further tinkering (at least for the time being).

Saturday, March 17, 2012

New iPad Display = Awesome!

iPad 2 Screen Capture
If you were waffling on whether or not to get the new iPad, debate no more. If you've been debating as to whether you should save that extra hundred bucks and pick up an iPad 2 at its new low price of $399, don't waste you money on what is now an antiquated product: spend the extra Benjamin. If for no other reason than its new HD display, the new iPad is so far superior to the prior model as to render it all but obsolete.

iPad 3 Screen Capture
This is not hyperbole. After viewing the stunning clarity and richer colors of the new display it's actually hard to believe the iPad 2 screen once looked sharp and clear. By contrast, it is in fact horribly pixelated and muddy. Setting the two devices side by side reveals the difference right away: the new iPad has far more vivid colors and crisp, sharp edges, bringing out a wealth of detail altogether missing on the prior version. I can't imagine even using the older device again: why would you want to view fuzzy images and blurry text when you can enjoy the clarity of the new display instead? So if you're considering a trade-in, I would highly recommend it.

I had first noticed this discrepancy in image clarity when comparing the iPad 2 with the Kindle Fire screen, which has a higher pixel density that made the images stand out in sharp relief beside the iPad. Not only is the Fire clearer, but the images are brighter and more intense. Now, by comparison, the new iPad makes the Fire look blurred and fuzzy - although to be fair this is due more to the harsh restrictions imposed on image file size in Kindle ebooks than the device's display capabilities: my images are uncompressed in the iBooks edition, while the Kindle version requires a fair amount of jpeg compression to fit within the limits.

If you click on the images above and compare them sequentially you'll see some of the difference in quality between the two iPads. Both are screen captures from the same ebook file, with the iPad 3 image scaled down to the size of the iPad 2's 1024x768 resolution (the new iPad is twice that at 2048x1536). The difference on the device itself is vastly greater than seen here, since the screen caps themselves lose some clarity in transfer (Blogger adds compression of its own for image uploads, but since it's the same for both, the comparison should still be relatively accurate, if not the actual clarity and brilliance of the images). But even by these examples you can clearly see the difference.

I have harped quite often here over the past few months about including the highest resolution images you can manage in illustrated ebooks, and this is the reason why. These larger images are vastly sharper than those of fixed layout ebooks formatted for the iPad 2 dimensions that I've looked at today: some of them look utterly terrible (particularly those that had to be scaled up even to fit the iPad 2). While the new display does an amazing job of calculating the extra pixels required to fill the higher resolution screen, those images suffer from not having enough pixel data in the source file to scale up to the new size, let alone be zoomed even further by the user.

However, I will say that I am no longer terribly concerned about the quality of images that have been formatted at the largest size currently allowed in iBooks, which is two million pixels (1.1 million less than the new display's 3.1 million total): the relatively smaller amount of scaling required for these images is handled admirably by the new iPad's quad-core graphics processor, both quickly and, most importantly, quite accurately.

Sunday, March 11, 2012

KF8 Fixed Layout Template UPDATED

Zoomed Image with Live Text
Just a quick post tonight to let you know I've updated the KF8 Fixed Layout Template to include some changes made today.

It's been bothering me for some time now that the comic sample provided by Amazon is just a bunch of images with the text included. Aside from the Panel View feature it's really little more than a pdf, and as provided you can't even zoom the full page image like a pdf. But not having live text in zoomed images to me defeats the whole point of going to the trouble of creating illustrated ebooks in the first place. After all, what's the point of an electronic text device that doesn't support electronic text?

Having worked out how to use the zoom functions for both text and images, the next step naturally was to suss out how to include them both within a single mag target. As you can see from the image on the left I figured it out. That's a zoomed image with live text included, and not by using a separate background image in a text box, but by actually overlaying text onto the magnified image. I'll explain how to do this in the tutorial, part of which I now have to revise.

I had started working on the second part of my KF8 Magnification Region tutorial this afternoon, but got sidetracked with this for several hours instead. Consequently, I didn't finish writing it. But I thought I'd post this up along with links to new template files that include the changes, so that you can look it over in the meantime if you like.

KF8 Fixed Layout Template:



See the "Templates" link above for information on the new updated templates.

Saturday, March 10, 2012

Understanding KF8 Region Magnification

KF8 Fixed Layout Target Mag w/Live Text
There seems to be a fair amount of confusion and uncertainty concerning the region magnification feature in Kindle Format 8. This is certainly understandable considering the vague and often obscure treatment the subject received in Amazon's Kindle Publishing Guidelines, as well as the sketchy examples provided in the sample files themselves. Given the resources at Amazon's disposal one might think a top notch technical writer might be among them, but this doesn't seem to be the case.

In a recent post I provided a sample file of my own, complete with notes defining its component parts, but only marginally describing their several functions and variations. Therefore, in the interest of adding clarity to a rather muddled subject, I thought it might be useful to provide a bit more information here, in something of a mini tutorial. In addition, given the discussion in my last post concerning live text, I'll talk a bit more about that as well.


The first requirement for region magnification to function correctly is an entry in the metadata section of the content.opf file stating that the feature is active:
<meta name="RegionMagnification" content="true"/>
There are ostensibly two modes for using region magnification in KF8: one for text and one for images. As presented in the Guidelines the former applies to children's books and the latter exclusively to comics, with a "hybrid" method possible for zooming text in comics as well. But this is not actually the case. In fact, the region magnification method has nothing to do with the type of book at all, and you can use either one - or both - zoom methods at any time, regardless of the type of fixed layout you choose. It is the "RegionMagnification" entity that makes this possible, not the book type. Which brings us to...
<meta name="book-type" content="children"/>
<meta name="book-type" content="comic"/>
The allowed metadata values for the book-type are listed in the Guidelines as being either "children" or "comic," but the entity itself is also listed as being "optional." In other words, you can leave it out and still retain the region mag functions. While the description for the book-type entity states that it "provides additional reader functionality, specific to the classification of the book," it does not say just what that functionality is. Given that the sections dealing with children's book and comics focus primarily on region magnification features, the assumption is that that is the "additional functionality" referred to. But again, this proves not to be true.

So far as I can tell, with regard to the region mag functionality it doesn't matter which book-type you enter, in which order you put them if you enter both, or if you enter one at all. There is no change in region mag functions in any case. The only caveat to this is that the background image pinch-and-zoom feature discussed in my prior post is disabled with the "comic" book-type chosen (or entered first if both are given). But this is a feature overlooked by the Publishing Guidelines entirely, as if Amazon were unaware that it was possible. Certainly there is no description of it, or its use.

This leaves us with the question of what exactly the book-type is in there for. Perhaps this will be revealed in time as KF8 is rolled out further to apps and devices beyond the Fire. Possibly it has to do with product classification in the Kindle store, simply as a category definition, although the Guidelines state specifically that there is some sort of "additional functionality" involved. But what that is I cannot say.

[UPDATE: Later versions of the Kindle Publishing Guidelines changed the description of the book-type attribute to state that it removes reader functionality "which may not be relevant for certain books such as children's," and specifically lists the share function as being disabled.]

Making the issue even more perplexing is the fact that live text is available in fixed layout KF8 files so long as you don't enter a book-type: both the "comic" and "children" book-types disable all live text functions. But if you leave the book-type metadata line out of the OPF the fixed layout KF8 will have all the live text features active, as well as region magnification and full bleed spreads.

Thus, at present there is no clear reason to include a book-type at all, so far as I can see, except for...


A second point of obscurity with regard to KF8 is exactly how large image files can be and under what conditions. Prior to the inclusion of Section 5 (on Comics) in Version 2012.2 of the Guidelines, released just a few weeks back, the stated maximum for images was 256 Kb. But this in itself is inconsistent, since its single mention in Section 3.5.2 on page 19 is followed immediately by two apparently uncorrected references to the original size limit of 127 Kb. And now in Section 5.1 that restriction has seemingly been increased to 800 Kb - at least for graphic novels, since that is the only section in which it is mentioned. Therefore, it's unclear exactly what the limits are, and where they apply. This clearly illustrates why you need to hire a good tech writer in the first place (and an even better editor afterwards).

KindleGen itself seems to make no distinction in the file size so far as I can tell with regard to the book-type chosen: 800 Kb images compile successfully in either case. I've only had KG abort the conversion twice for images too large, but I have not been able to reproduce the variables that caused it (that's what you get for not controlling your variables).

As for KDP, my tests have shown that files with the book-type "children" or no book type at all are compressed upon upload at a somewhat higher rate than files with the "comic" value, a rate that varies considerably depending on the input file size. This is further complicated by the fact that KindleGen compiles image content differently for each book-type as well, with files of the "comic" type created at a larger size than those of the "children" type, both of them larger than the source epub itself. Thus, comics will have a better image quality overall than children's book in KF8, but not so much that the difference is disastrous, or even readily noticeable to the average viewer. And the live text functions are, to my mind, far more important to the user experience than a slight loss of image resolution.

That said, the fact that KDP compresses files at all is unacceptable to my mind, since it should be my choice how my content is presented. But as there is no way around it (aside from selling the files from your own website), for now we're stuck with it. You'll have to decide for yourself how much compression is acceptable.

As a side note, uploading the source .epub file directly to KDP has not proven successfully at all. It appears that KF8 uploads are restricted to KindleGen created source files.


1. Reasons For Using A Book-Type Value:
  • Possible (but currently unspecified) "added functionality" at some point
  • Lower file compression upon upload to KDP if "comic" value is used
2. Reason Against Using A Book-Type Value:
  • Live text possible in fixed-layout KF8, including full search, bookmarks, dictionaries, highlights and annotations
  • Background image pinch-and-zoom using double-tap outside of mag regions (functional with "children" but not "comic" book-type, but only if the img src insertion method is used)
  • MagTargets become visible on tap or hover, aiding in locating and positioning
  • Unnecessary for Region Magnification features to function
Alright, now that we've gotten all that out of the way, let's get on with the RegionMag details...


As mentioned, there are two different types of region magnification, respective to text or image content. And there are two alternate ways of presenting them: either with or without a background lightbox effect, in which the unzoomed areas are shaded. There are also a number of variables for each. The sample template I've provided in an earlier post has examples of them all so that you can view the code and use it as a guide or basis for your own project. The following explanations will presume you've downloaded that and read my prior posts on KF8, rather than wasting time rehashing all that here.

It helps to think of region mag as a series of boxes within boxes, or windows over windows, if you will. Each one is formatted separately and visible when activated or uncovered by deactivating the one on top. An example of a complete set of html elements for a fixed-layout page with region mag for text without a lightbox might be:
<div class="fs"> 
<img src="../images/example.jpg" alt="example" class="image"/> 
<div class="txt mag1"> 
<a class="app-amzn-magnify"
<div id="mag1-text">
<p>Content to be zoomed</p>
<div id="mag1-magTarget" class="target-mag1"></div>

The first div container holds the overall content, and is formatted in the css to the full size of a book page (which is not necessarily the size of the display, although it can be, as it is in my template). You then find the background image reference, which in this case uses the "comic" img src insertion method rather than the one found in the "children" example, which I don't find useful and won't go into here, since it locks the background image and we're discussing magnification functions here (for the record, I employ that method on the contents page of the template just so you view the code and use it if you like). Using the img src reference allows the background image to be zoomed by double-tapping on it, as discussed in my prior post, which has innumerable benefits for the reader.

Next we have our first div element containing the content to be zoomed: <div class="txt mag1">. The txt  and mag1 references refer to two separate entries in the css. In this case, the txt value simply defines the container as using absolute positioning, rather than the default relative as defined in the fs entity. You could just as easily use absolute positioning for the default and do away with this, but that will depend upon your page content and personal preferences. It's often easier to position text relative to its surroundings, although in fixed layout you'll likely use absolute positioning for text more often than not. The important point is to use absolute positioning to locate your content containers on the page; otherwise it will become really cumbersome when you start to position multiple div elements on the same page, such as in a graphic novel.

The mag1 value references the following css entry:
div.mag1 {
top: 50%;
left: 10%;
width: 80%;
This positions the content container starting halfway down the page and 10% in from the left. With the width set at 80% this leaves 10% for the right margin as well, so that there's no need to add a right: value. The height is determined by the content itself. The important thing to remember here is that these values position the container for the source content on the page: that is, the unmagnified text or image elements contained within (more on images in a bit).

The following JSON element is the code that enables and directs the magnification function. The app-amzn-magnify element and its subsequent data... tag have no reference in the css; rather, these call functions in the Kindle software itself, and must be written exactly as found up to the brackets, which contain the variables you control.

The first of these is a targetId which identifies the region to be magnified: the target. This reference must contain the relevant div class value as its first element (here mag1), followed by -magTarget. This element allows you to format the position and width of the area that can be tapped on to activate the zoom, but not its height - that is determined by its content, which can be formatted differently, or use the same formatting as its source content, as is done here. I'll discuss the the alternate formatting variation shortly. Keep in mind, this is NOT the magnified region itself, but the tap target; that is, the zone in which a double-tap will activate the zoom and display the magnified content. As mentioned earlier, one of the key benefits of deleting the book-type entry from the metadata, at least for content creators, is that it allows you to see the tap target (as a gray box) when you tap on it. This helps immensely with positioning (which, again, I'll get to in a bit). The tap target positioning data is entered in the css with an id selector:
#mag1-magTarget {
top: 40%;
left: 0%;
This allows you to create multiple tap targets on the same page by creating unique ids for each. You can see an example of how to do that on page one of the template. Since I haven't entered a width value in this example, and set the left positioning to 0%, the magnified region will span the full width of the screen (and as high as needed to accommodate the enlarged content). You can, of course, format the width as you see fit, but since the idea here is to magnify the content as much as possible, in most cases you will want to use as much of the display as you can. Also bear in mind that when you magnify content, the source content disappears, so you will want to position the magnified region to cover the area of the source content. However, there may be times you could use this to creative effect to make one thing disappear while another appears elsewhere. Use your imagination.

Now, if you look at the bottom line you'll notice that the targetId value appears as the first element in that string, as its id value. This in turn references a second div class value, here target-mag1, which is the css entity that allows us to format the magnified region and its content. This value can likely be whatever you want it to be, since it's just a reference to a css entry, but the convention used seems about as clear as you could want. The css entry for this in the template is: {
position: absolute;
display: none;
font-size: 150%;
padding: 15px;
border: 3px solid #000000;
border-radius: 8px;
background-color: white;
opacity: .95;
This is pretty straightforward formatting, but the important factor to mention here is that the font-size value is where you determine the amount of magnification for the enlarged text. This value is a percentage of the source value, so that if the source text is set to 120%, the zoomed text will be 150% of that. Of course, if you used pixels or ems to format your source text it will just multiply that amount.

In this example the magnified region is filled with a background-color, but you can insert an image instead:
background-image: url("../images/background.jpg");
This will set the referenced image as the background, with its position defaulting to the upper left corner and any excess beyond the borders hidden. You cannot move this image or resize it, although you can use different images in each instance. I use one the size of the full screen so that no matter the size of the mag region it will fill it up.

A note on the opacity value: it's essentially worthless. Unfortunately, it applies to all content included in the magnified region, text included, so you can't create a 50% transparent background without rendering your text a dim shade of grey. Not terribly useful, in my opinion, unless of course you want grey text in the first place. On page 2 of my template I left out any background at all so that the zoomed text appears over the fullscreen image. However, this is only helpful if there is no conflicting content in that image. If you work out how to make a semi-transparent background with black text in a mag target, let me know.

As for the magnified content itself, we need to return to our JSON object and discuss the last two entries. The value of the sourceId points us to the content to be zoomed: in this case mag1-text, which references the content found immediately below. In this case there is no relevant css entry, as this is simply a locator for the content, and the formatting is all done as normal within the content section itself. Thus, you can create and format any content you like as usual, and magnify it as is by simply enclosing it within the sourceId container. In this example, all content is magnified intact along with its formatting.

However, with fixed layout it may often be the case that magnifying the text as is will force it beyond the edges of the screen. For such instances as this, you can alter the formatting of the zoomed text by simply deleting the sourceId entry and its reference from the JSON object and source content section. You can then add alternately formatted content (or other other content entirely, located in a different position altogether!) to the magTarget at the bottom:
<div id="mag1-magTarget" class="target-mag1">
<p>blah, blah, blah...</p>
Finally, the last entry in our JSON object is the ordinal, which simply defines the order in which the magnified areas are shown if the user swipes from one to the next. This is useful primarily for graphic novels in which the panels may overlap or not run in a logical sequence down the page. Otherwise the sequence progresses in order as entered in the html.

That wraps up the text zoom feature. However, as this has run on longer than intended the image portion of this tutorial (including the lightbox feature) will have to wait until the next post. I'll try to work on it tomorrow, but it may take a day or two to get it finished. I hope you find this helpful, and that it didn't simply add more questions to those you had already.


The definitive guide to the Kindle fixed layout format, this fully revised and expanded tutorial will take you line-by-line through two working templates, including both the content and support files, as well as all layout and functionality features, explaining in painstaking detail what each element is for, and what your options are in every instance. Also included in the ebook is a code to download both templates for free!
Add to Cart
$9.99 [8.94 Mb]
Kindle reflowable .mobi format