R. Scot Johns's Blog, page 13

Fantasy Castle Books Website Update

My intention when migrating my publishing homepage to a new web host was simply to add some features missing from its prior home at Yahoo and bring a few new domain names into the mix (more on this in coming posts). This almost immediately turned into a major fiasco and has ultimately resulted in a complete rebuild of the site, which is only in its first initial stages. The new banner shown above was first among the changes; the new site needed something a bit more bold and adventurous, as well as slightly more artistic.



Yahoo has hosted Fantasy Castle Books for over three years since its inception in mid-2008. Since then the site has grown to include well over a thousand pages and nearly a hundred downloadable files, including reference works and early drafts of both my first novel and the new one. But it was in danger of becoming bloated and difficult to navigate (if it had not already). So a redesign was hiding somewhere in the back of my mind, waiting for its opportunity to arise.



Meanwhile, Yahoo's Sitebuilder had become problematic in many ways. Foremost of these was its lack of adaptability to a mobile environment, rendering the website all but illegible, not only on small phone displays, but even on the iPad's spacious screen, where the text resized incorrectly so that it overlapped both itself and the images. Additionally, Sitebuilder's e-commerce features are weak and unimpressive to say the least; my first excursion into direct digital downloads a year or two ago was far from satisfactory, and far more difficult to set up and manage than should be necessary. I wanted something vastly more robust than Yahoo offered. In addition I've been wanting to control the site content a bit more closely by including an area for registered guests where the bonus content can be housed, as well as an email newsletter for informing recipients of site updates and events related to my writing.



So it was time to up and migrate, and spring break seemed the ideal time to do it, particularly given that my Yahoo renewal was fast approaching. Initially I intended to transfer the files via FTP and import it into Dreamweaver. But this proved problematic for a number of reasons, due primarily to the inability of Dreamweaver to interpret some of the code in Yahoo files, and the fact that Yahoo Sitebuilder creates a file structure that is not relative to the root folder, but rather to the file location instead, rendering the links unusable once the files were moved to their new host.



So to make a short story long, I've just decided to completely rebuild the site. It was time for a new look anyway, although I wasn't planning on spending the time on it right now. Still, what needs doing must be done, so there's nothing for it but to get on with it.



This means my Nook project will be put on hold for a few weeks or so, although I plan to get back to it as soon as possible, for those of you who've been wondering. Also, be sure to visit the new site and register with the email opt-in, as I plan to start sending out updates as new content is created and added to the site. There will eventually be an e-commerce function with direct downloads available (and possibly signed print editions as well). All ebooks sold from the website will be DRM free and include access to all formats available, not just one, with free updates to any future revisions (another reason to sign up for email notifications).



Finally, I will be starting another blog sometime down the line, which is something I've been meaning to do for quite some time. This blog has been, from the start, fairly technical in its orientation, focusing on various practical issues involved with self-publishing - from print on demand to marketing to ebook formatting. But I've been wanting to start a blog where I only talk about the creative aspects of the process, for those more interested in what it is to be an author or an artist. That site will be hosted at my own domain (www.rscotjohns.com), but that's another project for another day.



For now, click on the "Fantasy Castle Books" tab above to visit the new site. Once there you can click the "Scot's Blog" tab to return here. At the moment there's not much up - just a homepage and a contact form - but more is coming soon. Leave me a note to let me know what you'd like to see, and if you've visited the previous site, what you'd like me to keep from the prior version. I plan to retain a lot of the content, but much of it is outdated (such as the blog tour archive for example), and will be jettisoned.



As always, this is yet another obstacle in the way of getting down to some serious creative work, and it will likely put my current project off by another month or two. I'm already better than a year behind schedule, so that's nothing new. But in the end it will all be for the best.

Website Temporarily Down

I am currently in the process of migrating the Fantasy Castle Books website to a new host, so it will be unavailable for a short time. While doing so I may use the opportunity to do a redesign, so bear with me as it will likely take a few days. I've been planning to do this for awhile, but have put it off due to other obligations and more pressing concerns. All file links from the tutorial posts are still working, as I've transferred those first. But the page links at the top of this blog will be non-functional for a little while.

Nook Digital Replica Plus

Not satisfied with leaving out that third of the three leading ebook ecosystems, I purchased a Nook Tablet this weekend to complete the triumvirate of Amazon, Apple, and Barnes & Noble (I don't count Google Play among them, and likely won't until they get a major reader of their own going). While Barnes & Noble have yet to release their fixed layout spec to the general public, there is (I think) enough info out that I can piece together my sample chapter in their Digital Replica Plus format. I will post it here as soon as it's completed, and/or provide updates on the progress, depending on how it goes.



The new Nook format, by the way, is just another iteration of an ePub morphed to meet the needs of their particular device, both in a way they like and one which is unique enough to separate it from the competition (i.e. Amazon), as well as making it proprietary to their content ecosystem. It has some unique features that set it apart (and one I tend to like, at least so far), but underneath it's just an ePub.



BN are, in fact, still working on the DRP format, which is why it has not been officially released, even though the major publishers are already using a version of it to fill the shelves with children's books and comics. The latest rumors have BN working on an In Design plug-in that will allow content creators to save their ID files in the new Nook format, and if that comes to pass in a way that functions better than Amazon's half-ass attempt it will be a major coup. But BN should have a far easier time of it, as their new format is vastly simpler in its structure, with full page images for the "fixed" part and reflowable overlays for the magnified text view, giving us the best of both worlds.



So while the spec and ID plugin should be forthcoming in the not-too-distant future, I'm not one to stand around and wait if I can help it. Unfortunately, with the release of the Nook Tablet and titles in the new format, the BN partition of both this device and the Nook Color have been hidden from prying eyes so that no one can look at what's underneath the hood in these fixed layout ebooks. Downloads from the website or the iPad app have also been disabled for titles in this format, and they do not show up in the B&N Downloads folder on the device. Of course, the first thing I did was root the Nook to run Android and dug into it with File Explorer, but there's nothing there to see that's of any help. Fortunately, there's a test file up online and a bit of information on the replica map over on the ePub Revision Wiki page, which should be enough to get me started. They are working on some very cool stuff, by the way, so I'm more excited than ever now to see what they come up with.

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.

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.

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 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 iBooks, which are naturally suited to the larger screen. 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 it.





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.

KF8 Fixed Layout Image Zoom Tutorial [Updated]

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.



THE HTML CODE:



1 <div class="fs">

2
3 <div>
4   <img src="http://feedproxy.google.com/~r/TheAdv..." 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>

21

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="http://feedproxy.google.com/~r/TheAdv..." 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.





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.



ADDING LIVE TEXT



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:



      div.target-mag {

            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 div.target-mag element, but with the img entity appended. The first of these defines the actual image resolution:



      div.target-mag 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:



      div.target-mag img.zoom100 {

            position: absolute;

            height: 1024px;

            width: 600px;

      }



      div.target-mag 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...



MAG TARGET SIZE & POSITION



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.



CREATING A SEMI-TRANSPARENT FILL



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>

            </a>

      </div>




      <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>

            </div>

      </div>


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;

      }



      div.target-mag2 {

            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.



      div.target-mag2-lb {

            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.



UPDATE: SATURDAY 3-24-12



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. My apologies for the confusion.

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.



THE HTML CODE:



1 <div class="fs">

2
3 <div>
4   <img src="http://feedproxy.google.com/~r/TheAdv..." 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>

21

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="http://feedproxy.google.com/~r/TheAdv..." 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.





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.



ADDING LIVE TEXT



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. You might also note that there is a .hide tag in the CSS that is never actually referenced in the HTML itself. This and the display value are elements employed by the Kindle software itself to make the default text disappear when the magTarget appears, so make sure that you include them. 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:



      div.target-mag {

            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 div.target-mag element, but with the img entity appended. The first of these defines the actual image resolution:



      div.target-mag 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:



      div.target-mag img.zoom100 {

            position: absolute;

            height: 1024px;

            width: 600px;

      }



      div.target-mag 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...



MAG TARGET SIZE & POSITION



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.



CREATING A SEMI-TRANSPARENT FILL



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>

            </a>

      </div>




      <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>

            </div>

      </div>


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.



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;

      }



      div.target-mag2 {

            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.



      div.target-mag2-lb {

            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.

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).

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.