NOTE: The following comprises the contents of a post from March 10th of 2012. This was the first in-depth post on the web addressing the topic of the region magnification feature in Kindle fixed layout, then still relatively new, having been released just four months earlier in November 2011. It is presented as a brief tutorial on the subject for those wanting to add zoom features to their pages. Bear in mind that this is a very rudimentary overview, but it clearly describe the contents of this unique Kindle code element in a brief and concise manner. Of course, a complete and thorough explanation of these features and their many uses can be found in the published guide, How To Make Kindle Comics & Childrens' Books.
There seems to be a fair amount of confusion concerning the region magnification feature in Kindle Format 8. This is certainly understandable considering the vague and obscure treatment the subject received in Amazon's Kindle Publishing Guidelines, and the 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 about that a bit more 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 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 - at any time. The "RegionMagnification" entity makes this possible, not the type of fixed layout you choose. Which brings us to the next point of confusion...
<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 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 actually is. Given that the sections dealing with children's book and comics focus primarily on region magnification functions, 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.
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 the file size limits.
NOTE: A discussion of the original mobi7 image size limits has been removed here, since it has been discussed earlier in the tutorial series.
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 dimmed. 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:
<img src="your-image-source" alt="example" class="image"/>
<div class="txt mag1">
<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, and 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 (although I use it on the contents page of the template just so you can see how it works).
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 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 this will depend upon your page content and personal preferences. The mag1 value references the following css entry:
This positions the content in a box 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 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 references 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 other 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 in my last post, one of the key benefit for content creators of deleting the book-type entry from the metadata is that is 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:
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. 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 can use this to creative effect to make one thing disappear while another appears elsewhere.
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:
border: 3px solid #000000;
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:
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.