FINAL SLASH

When I first started messing with Kindle books I inserted images with this format:

    <img src="name.jpg" width=500 height=750>
 
Later, as I tried to get closer to the ePub syntax, I added:

    alt="subject of photo"

after the sizing specs.

Finally, I added the final slash before the end angle bracket.

In XHTML, which is used by ePub, so-called empty or void tags have to be closed. So I started using slashes like this:

    <a name="chap_1"/> for anchors

    <br/> for break tags

    <hr/> for horizontal rules
 
Now my image insertions looked like this:

    <img src="name.jpg" width=500 height=750 alt="subject of photo"/>

And I fell right into a problem I hadn't seen before.

In my novel MAD MINUTE I had ganged up three images for my chapter starts: a small image of a Nike Hercules missile and images of digits to form the chapter number.

Put one image right after the other inside one paragraph, they run side by side horizontally. You just have to make sure the combined width specs come in well under the width of a Kindle Classic (around 600 pixels).

And it worked, not just in Classic and DX and iOS apps, but in Fire and Paperwhite, too.

Until I added the final slash.

Before I go on with this saga, I need to back up a moment.

Not long ago I read a blog by an ebook formatter who was using a width spec of 98%. This way, images that go almost full screen in Kindle Classic (around 600 px) will not be shrunk to a tiny little thing covering less than half the width of a Kindle Fire HD 8.9". That boy's got a lot more pixels to fill up.

It made sense. I could size all my "full-page" at 98%, insuring that every app got the full-size image, across the board.

But when I tested it, I found Kindle Classic (and others) didn't know how to handle percentage specs for width. When in doubt, mobi-code apps force the image to go full size—the actual, GIMP-created size of the file.

Okay, I could live with that. It just meant that every title page or chapter-start image I generated in GIMP would need to have an actual size equal to the full width of a Kindle Classic page.

Set the width at 98%, and the other guys (Fire and Paperwhite) would benefit from going from one margin to the other (well, almost).

I had tried to revise my multiple image chapter start by using percentages: 10% for each image.

But as I said before, Kindle Classic balked at the percentage spec—the images all went full size.

So I went back to sizing the images in pixels.

But now even THAT wouldn't work: The images still went full size.

But wait, it USED to work, right? In my earlier version of MAD MINUTE it worked! Didn't it?

I checked the old file, just to be sure, using Kindle Previewer: And yes, it worked!

Why wasn't it working in my newest book?

You probably already guessed the answer, but it took me a while to compare the files and realize that the ending slash before the last bracket was ruining everything.

So I went on with my life. I worked AROUND the problem, resizing all my images in GIMP so they would work full size.

There was no problem with images designed to go full page—I'd already fixed that deal. It was when I created images of individual letters (as super-big capitals for the first words of chapters) that I got into more trouble. Some of these smaller images were right at the edge of pixelation.

I found I needed to select extra wide fonts, like Rockwell Ultra-bold and Broadway and Goudy Bold, or the images of individual letters looked too ragged.

I thought I was going to have to live with this annoyance.

Then I remembered something from my research into the origin of the final slash in XHTML. Older browsers went nuts when they ran into that thing. The solution, add a space before the slash.

I'd seen that space before, when I went hunting for working versions of the OPF file. End tags had slashes, and some of those slashes had spaces in front of them. But not all of them. It looked chaotic. I wondered how you decided when to use the space and when not to. Did it really make any difference.

One thing I noticed, Kindle didn't seem to care if there was a space there or not. I removed them all. And had no problems.

Now I wonder.

When I checked some test code at an HTML validator site, I got no argument when I put one or more spaces in front of the final slash. (But leave out the SLASH, you'll get a good talking to.)

I went back to my Kindle image tags and inserted a space before the final slash.

Bingo! It was like the end slash wasn't even there!

(Actually, there were some minor items: In Paperwhite, using the slash without the space made the images slightly smaller; in iPad, the images were taller [but not wider] with just the slash in place; only Fire seemed the same for all—slash, no slash, slash with space in front.)

Now I could go back to sizing in pixels in Kindle Classic. That was nice, but it didn't solve the other problem. With or without a space before the slash—or without the slash itself—Kindle Classic reverted to full-size images when the width was given in percentage.

And without using width=98%, how could I get my images to spread out full width on the HD models?

I thought the solution might come from my dalliance with drop caps.

Drop caps only work in Fire and Paperwhite (kf8), so if you want to use them there, you have to make arrangements for the older versions (mobi code guys like Classic, DX, and iOS). I thought the answer for the full-page image problem would be to split the code, giving different instructions to the kf8 apps and the mobi apps.

Turns out splitting the code wasn't necessary. You do need new code, though, a new image class, in fact, but it doesn't have to hide behind a kf8-only screen. Add this code to your style section:

   img.wide
    {width:98%;}

Now some of my image insertion codes look like this:

    <img class="wide" src="name.jpg" width=500 height=750 alt="subject of photo" />
 
Be aware there is some rather mysterious interaction between the kf8 percentage spec and the pixel specs in the tag. If the spec in pixels creates a bigger image than the percentage, kf8 apps go with the pixel specs, even if the image gets all disproportionate. You'll have to test these guys in actual use, in Previewer at least.

Recently, I actually had a chance to use this information.

I just put up a revised mobi of HOT STATUS. I set my full-width spec to 98%, but there were problems. In my Photo Gallery of full page images I had five or six that refused to show up in iPad. I needed to be able to lower the size specs of those images to get them to work.

After I put the new code in place (and added the space in front of the final slash), I could do just that without having to go back into GIMP and actually change the size of those images—which, if I had done so, would have affected all the other apps.

This new code also led to a fix for the use of large letter images at the start of new chapter paragraphs. What I wanted was a bigger actual image resized by code to a smaller one. To work the compromise between Kindle Classic font size one to font size six, you need a letter (boxed or not) around 30 or 32 pixels square.

Here's the new code:

    img.letter
   {width:12%;
   font-weight:bold;}

Now the code for a chapter start paragraph might look like this:

   <p class="start"><img class="letter" src="rockwell ultrabold T.gif" width=32 height=32 alt="rockwell T" /><b>his particular morning</b>, ten-year-old...
 
You can also add a float:left spec and use this technique for "drop" image letters:

   img.drop
   {float:left;
   width:12%;
   margin:10px 8px 0px 0px;}
   
Crank up your Kindle Previewer and get to work messing with this stuff.

Or don't: You COULD just stick with "font-size:large" or "font-size:x-large" for your big capitals and be done with it. Or set everybody to 2 em. At least the capital letter will size up and down with the font.

Remember: Images of letters never change size, though a shifting font size makes it look like the image is jumping up and down. If we could just figure out how to keep readers from messing with the font size...

One brave strategy (or do I mean reckless?) might be to pick a font size and stick with that. When you check out a book that just went up on Kindle, the online Previewer is set to Fire at font size 3. You could put your entire attention on that font, make it look perfect, then take a quick peek at the rest to be sure it doesn't look TOO outlandish at smaller and larger fonts.

Boy, would THAT be a relief!

Update: Part of what I said above was right, and part was wrong. I still think you should put the final slash in, and putting a space in front of it won't hurt anything. But my reasoning was wrong; it had nothing to do with older browsers learning to live with the final slash.

In fact, the first image insertion tag I displayed above, the one ending with the sizing in pixels, WOULD fail if I put a slash at the end (without a space to protect it). But the revised tag, using the alt image title at the end, would also work just fine with a slash at the end (with no space in front of it).

Turns out the problem was putting a slash right behind the pixel spec. It apparently contaminated the spec and made it invalid. Kindle Classic and DX need both specs to size properly, so they went full size. Kindle Fire (and also the iOS apps) only need one spec to size an image, so they were unaffected when the slash turned the final spec to junk.

Also a fix: put the pixel specs in quotes. Anything to keep that evil slash from rubbing up against the raw numbers. (It's also needed for ePub.)

And I now make some other changes:

     <a name="chap_1"/> for anchors -- becomes: <div id="chap_1"></div>

    <br/> for break tags -- becomes: <br />

    <hr/> for horizontal rules -- becomes: <hr />

All to make the book ready for ePub. More about that later.