Thursday, March 29, 2012

Seravek Font bug in iBooks

I wanted to set my latest book in a sans-serif font so I chose one of iBooks' default fonts: Seravek. This morning, doing a last minute check, Seravek had mostly disappeared. I immediately suspected nefarious setting adjustments by iPad-stealing family members, but it turns out iBooks was the culprit.

Look at this:

Not Seravek

If you don't know what Seravek is, I'll tell you, it's not that.

I recompiled my book a bunch of times, looked at it on my old iPad and everywhere, the font had disappeared. I wondered if iBooks had somehow changed between yesterday and today. If Kindle Previewer was going to update itself without my involvement, maybe iBooks too?

Then I changed the font size:

Seravek back

And the Seravek came back. Weird. It turns out that Seravek works fine in all font sizes except 5. And in font size 3, it doesn't work in the subhead, but I wonder if that has to do with caching, since I had that set as a serif font for a while (though not in this example!)

Photo Mar 29, 11 34 33 AM

Since there's no other sans-serif default font for iBooks, and I didn't want to use Optima, in the end, I decided on Muli, one of Google Web Fonts offerings:

Muli

Remember that readers can always select a default font if they so choose.

Wednesday, March 28, 2012

Kindle ignores everything when ID gives it multiple classes

I'm about to publish an anthology of stories based in Barcelona (more news soon!) and keep bumping into an annoying issue with (old) Kindle: if your InDesign document contains a styled paragraph with local formatting, InDesign will export the resulting EPUB with multiple classes, one for the base style and one "override" class with the extra bits. Unfortunately, Kindle throws up its hands at multiple classes and not only ignores the extra classes but actually ignores the base class as well, leaving the paragraph with no formatting at all. Ugh.

Here's an example from my new book.

Kindle-multiple classes

The paragraph that begins "Moving between the shadows" has no styling. It should be in italics with no indent, as shown in iBooks:

iBooks - multiple classes

I go look at the code, and find that InDesign has added an "override" style:

code-multiple classes

Why? Because I had added some local formatting in the original InDesign file. Oops. (You can tell by putting your cursor in a paragraph and looking at the Paragraph Styles panel... if there's a plus sign next to the style name, there's local formatting.)

InDesign-local formatting

Really, InDesign is completely within its rights by exporting multiple classes, they are perfectly standard. It is Kindle that is at fault here.

The easiest solutions is to avoid local formatting. This is a good idea in general, although I'll admit that when I just need to nudge something in my print version, I am not always strictly orthodox.

If you forget, and/or don't want to go back and change the print version, the second solution is to create a new style that contains the characteristics from the two applied styles, and apply it both to the HTML and to the CSS. Kindle can't say no to that.

screen_shot-27125

In general, I recommend doing a search through your XHTML files in an InDesign-generated EPUB document to find all of the override classes. Then, substitute them with better-labeled and less troublesome individual styles.

Also note that it is "old" Kindle that can't handle multiple classes, Kindle Fire supports them just fine.


Friday, March 23, 2012

Centering in ebooks across ereaders

A long time ago, I realized that the most basic parts of childrearing—eating, sleeping, and peeing and pooping—were by far the hardest to figure out. So it is with ebooks. It seems almost ridiculous to have to write a big, long complicated post about centering—something so essential and so fundamental—but I keep bumping up against it, so write I will. I hope I'll save you some sleepless nights.

Centering in ebooks involves CSS, the box model, inheritance, and ereader inconsistencies. The main problem with centering lies in not understanding how these aspects relate to each other.

The text-align property

I'll start with the simple. There is a CSS property called text-align whose possible values are left, right, justify, and center. But there is one very important caveat: text-align only affects inline-level objects within the block-level objects to which text-align has been applied. Let's look at that closely, since it is the source of many misunderstandings and thus errors.

Here is a simple p element that contains text.

<body>
<p class="center">Here is some text that should be centered</p>
</body>


And here is the CSS:

.center {text-align:center}

And here is what it looks like:

Preview: centeringex.html

You may think that it is the p element that has been centered, but you'd be wrong. It's actually the inline contents of the p element, an anonymous inline block, if you can stand the CSS parlance, or simply the text itself (if you can't), that is being centered. The p element itself is not centered.

How can you tell? We'll set the width of the p element to 60%, and then set the background color to yellow, so you can actually see it.

.center {text-align:center; width: 60%; background: yellow}

Preview: centeringex.html

You can now clearly see that the p element is still aligned left (which is the default in most browsers and ereaders) even while the inline text that it contains is aligned center within the p element.

Centering block-level elements

So how do you center a block-level element? The canonical way is to set the right and left margins to auto. According to the CSS spec, when both left and right margins are auto, they should be equal, and thus the item will be centered. And don't forget that unless your block element has a width that is smaller than the window size, you won't be able to tell if it's centered or not.

So, to center our p element, we'd have this:

.center {text-align:center; width: 60%; background: yellow; margin-right: auto; margin-left:auto}

And we would get this:

Preview: centeringex.html

This works on most major browsers and ereaders:

Centering-iBooks iPad

And is converted properly for Kindle Fire:

Kindle Fire Previewer - CenteringAcrossEreaders

(Regular Kindle doesn't support width and thus can't center a block-level element at all.)

CSS bug in ADE, NOOK, etc.

Unfortunately, ADE, and the ereaders based on it (like NOOK, NOOK Color, and presumably Sony Reader though I didn't test this last one), don't properly interpret the auto value for left and right margins, and the result is that the blocks are not centered:

NOOK Color centering

Independence of alignment of contents and of the block that contains them

Before we get to the solution, I just want to underline how the text-align properties and centering of the block level elements using automatic right and left margins are independent of each other.

That is, the alignment of the inline-level elements within a block-level element need not match the alignment of the block-level element. That is, we can center the p element within the window and then left-align the contents of the p element:

.mismatch {text-align: left; width: 40%; background: red;margin-right: auto; margin-left:auto }

And that should look like this:

Aligned left within centered block

Notice how the image and the text are aligned to the left within a box that is centered on the page.

Again, ADE, NOOK, and presumably Sony Reader, don't properly interpret the right and left margins set to auto:

NOOK centering mismatch

The Solution

The solution hinges on the fact that text-align only affects inline elements. (This is why simply enclosing an inner div in an outer div whose text-align property is set to center will not work.) We'll enclose the p elements in a wrapper div, whose text-align property we'll set to center, and then we'll set the display property for the p elements themselves to inline-block. The inline-block value is sort of a hybrid between inline and block, that for our purposes keeps the p elements starting their own paragraphs (like regular block-level elements) but allows them to be affected by text-align (like inline-level elements).

Here's the CSS with the new bits in bold:

.wrap {text-align:center}
.center {text-align:center; width: 60%; background: yellow; display:inline-block}
.mismatch {text-align: left; width: 40%; background: red;display:inline-block }


And here's our new HTML:

<div class="wrap">
<p class="center">Here is some text that should be centered</p>
<p class="mismatch"><img src="momo.jpg" alt="momo" width="200" height="150" /><br />This image and text will be aligned to the left within the centered block that contains them.</p>
</div>


Let's look first at iBooks on iPhone: (I've put it in landscape orientation just so it's easier to see, it looks the same in portrait.)

iPhone Centering

Everything is as it should be. Our boxes are centered, but the contents within them are centered and left-aligned respectively.

How about NOOK Color?

NOOK Color-centering inline-block

NOOK Color also likes this solution, even when Publisher Defaults are turned off (although then you have other margin issues).

And Kindle Previewer converts the file just fine for KF8 and the Kindle Fire ("old" Kindle can't center divs but maintains the text-alignment for the inline level elements):

Kindle Fire Previewer - CenteringAcrossEreaders6

But what happens when you view the ebook in iBooks on iPad?

iBooks iPad Centering

The boxes are centered as desired. But the text and image that should be left aligned in the lower box are now justified! Look at those ugly spaces between the words. What happened?

Now we've bumped up against iPad's default overrides. Remember that by default, Full Justification is set to ON, hidden away in the iBooks area of the Settings panel. I don't think most people who use iBooks will ever know this setting exists so ebook designers have to plan for it. You used to be able to add a span tag around the text that you wish to have aligned to the left, but that hack no longer works.

Thankfully, there is still a workaround. If you add the com.apple.ibooks.display-options.xml file to the META-INF folder, with the <option name="specified-fonts">true</option>, the justification that you choose in your CSS will be maintained, regardless of the Full Justification setting chosen. The user can still override your choices by choosing a different font in the Fonts menu, but at least the book will start out the way you want it:

iBooks iPad

To resume:

The text-align property only applies to inline elements within the block-level element to which the property is applied. It is inherited by block level elements that may be enclosed in the outer block-level element and in turn applied to the inline elements that the inner block level elements contain. If you need more info on block level vs inline, see the CSS spec or my my HTML/CSS book.

The canonical way to center a block-level element is by setting both margin-right and margin-left to auto. The fact that this is not supported by ADE or NOOK (and presumably not by Sony Reader or other ereaders based on ADE) is a serious bug.

You can center block-level elements by wrapping them in another block level element (a div), setting the text-align to the outer div to center, and then setting the display property of the inner div (or p or whatever) to inline-block.

iBooks on iPad has a default setting of Full Justification for text, which you can override by adding the com file to the META-INF folder. This has ramifications with respect to font choice, of course, as well.

iBooks on iPhone has the Full Justification setting, but by default it is set to OFF (presumably because of the narrow screen).

This should be much simpler.

And yes, it's true that I have no AT&T coverage in my office!


Wednesday, March 7, 2012

Bad Headers in InDesign exported EPUB

I've talked about this issue on Twitter, but I've gotten two emails about it this week, and because of installing a new language version of ID bumped up against it myself, so I'm going to write a quick post to make sure that everyone knows:

The first version of InDesign CS 5.5 had a serious bug that exported bad headers to EPUB. Specifically, it inserted an extra space in the DOCTYPE element of each XHTML document:

Extra space in ID generated DOCTYPE

This error in the DOCTYPE causes all sorts of problems, particularly with special characters, non-breaking spaces (@nbsp;), discretional hyphens (@shy;), etc.

Luckily, Adobe fixed the error right away and has made a free update available for both Macintosh and Windows. If you're using InDesign CS 5.5, I strongly urge you to install the update.

Here's what the proper DOCTYPE should look like:

proper DOCTYPE

Now, here's a weird bit of extra info that you'll probably never need. But I did, so you never know. I have both English and Spanish versions of InDesign CS 5.5. I originally installed and then updated the English version. When I installed the Spanish version, it overwrote the English. I updated it as well. Then, when I got sick of navigating in Spanish (and had finished De InDesign CS 5.5 a EPUB y Kindle), I renamed my Spanish ID folder, so as not to lose it, and installed the English version again.

I forgot to update it until yesterday, but when I did, suddenly the English version started coming out in Spanish—Spanish menus, Spanish dialog boxes. It was bizarre. And annoying. I still have no idea how that happened. I was definitely using the English version, and the menus and dialog boxes were definitely in Spanish. Anyways, I really didn't feel like reinstalling the English version again (and wasn't convinced it would help), so I rummaged around the internet (and complained on Twitter) until I found this very helpful post from David Blatner on InDesign Secrets, that explains how to change the interface of your version of ID—even if you don't own the other one. It did the trick and now my English ID is back to English. (I haven't dared open the Spanish ID :)

Thanks to Ester, who reminded me I really needed to write about this.

Thursday, March 1, 2012

Asymmetry on Twitter

I received an unpleasant email the other day from someone who had bought one of my books, followed me on Twitter, and then realized I wasn't following them back. They then unfollowed me, and when I sent word about my new subscription, they wrote me back to tell me that following readers of my books was just common courtesy, which I clearly lacked.

I've let it stew in my head for a few days, and though I'm sorry I made that person feel bad, the truth is I think asymmetry—the fact that you don't have to follow back those who follow you—is one of Twitter's most important features. Let me explain.

Twitter is my social media tool of choice, both for learning and for sharing. I consider the 140 character limit an absolutely brilliant and sublime innovation and I love how it trains us all to be editors, peeling away the layers of excess. I try to follow the tenets described in Tim O'Reilly and Sarah Milstein's excellent and newly updated The Twitter Book, especially that of adding value to the conversation. Still, I consider myself a difficult person to follow on Twitter, since my tweets are divided between two very distinct topics: ebook production and Catalonia, which have a limited amount of overlap. My followers generally have to bear a fair number of tweets on the other topic, often in another language. And sometimes I tweet a lot.

In short, I'll understand if you don't follow me. I know how it is. Which leads me to the second half of my Twitter life: the 500 or so people that I currently follow. You are all amazing. I learn so much from you. And unfortunately, I can't read half of what you write. Of course, I can't read even the tiniest percentage of what's on the internet, so I figure I'm doing OK with half of your helpfully filtered stream. Thank you.

But still, I worry about the other gazillion people, my disgruntled reader among them, that I don't follow. Not because I may be hurting their feelings, but rather because I'm missing out on what they might share. I'm sure I should be following some of them, but how to know? Once in a while, I look at people's profiles, and if something catches my eye, I might check out their latest Twitter stream, but as the list of people who I follow (and my to-do list!) grow, I get more and more reluctant to add any more information to my already overflowing banks. More often, I follow people that I have conversations with, who ask interesting questions, offer interesting links or insights, or well, who can help Catalonia become independent.

So I like Twitter's asymmetry. I follow lots of people who don't follow me, and lots of people follow me that I don't follow. I am honored when someone decides I'm worth following, but rarely insulted when they don't. Being able to follow anyone without the obligation that they follow me back has allowed me to connect to a much wider group of people than any compulsory following ever would have. I can follow Roger Ebert, Elisenda Paluzie, Neil Gaiman, and Miquel Calçada without worry of imposing or being a fangirl. I believe asymmetry encourages authenticity and also allows a more gradual connection which may well end up in mutual following.



For the record, I do have a Google+ account or page, but clearly haven't been there enough to even know what it's called. I'm on LinkedIn only because I wanted to be able to access the ebook discussion groups, but honestly, I need Twitter's 140 character limit in all parts of my life, so I barely ever go there. Plus, LinkedIn always seems to know more about me than I told them and generally gives me the creeps. If I don't follow you there, or talk to you there, just talk to me on Twitter.

And though I am on Facebook, I mostly use it for personal stuff, though, truth be told, my Facebook friends get a fair bit of information about Catalonia too. 



More of my books