Spec fonts with InDesign (and by hand)
Earlier this week, @snew_pleop asked the #eprdctn thread why fonts were not appearing as expected in iBooks. I wrote back, suggesting he check that the following is in the content.opf:
<meta property=”ibooks:specified-fonts”>true</meta>
I also mentioned that InDesign doesn’t write that line into the content.opf on export, so it needs to be included manually.
Before you could say zapf dingbat, @amarie tweeted that InDesign does, in fact, include that squirrelly font line.
In #eprdctn, it’s common to think you’re crazy when something you did successfully yesterday completely breaks down today. But I know that I add that meta property on a regular basis, so I wasn’t sure what the story was.
My confusion didn’t last long. I quickly realized that since I don’t often embed fonts (why don’t I? partly a throwback to when embedding wasn’t widely supported, but mostly as an acknowledgment of the power of the ultimate font chooser: the person reading the book), my content.opf lacks the needed metadata.
Here’s how the Export-to-EPUB screen looks when I export:
I leave the Include Embeddable Fonts box unchecked.
My InDesign export looks to see if I’ve embedded fonts. I haven’t, so there’s no ibooks-specific font metadata in the content.opf:
I insert it, like so:
I often use my own CSS. The option for this is under Additional CSS in the Export to EPUB screenshot above. I’ve developed a clean, simple CSS that I use for many projects; it’s easily mapped to InDesign documents that I create or that a client provides for EPUB creation. (I’ll post about using custom CSS soon.)
Here’s the CSS for the standard p tag:
Sometimes I spec a device-specific font set (iBooks includes Gill Sans):
Even though I’m not including an embedded font, I am spec’ing a font family, so the ibooks-specific font meta property needs to be present. Otherwise, ibooks will do what it wants with the <p> and <h1>, <h2>, etc. tags.
So, when you export, if you check Include Embeddable Fonts, InDesign will write the all-important ibooks-specific line into your content.opf. If you leave it unchecked, remember to add it after export, or be ready for ibooks to decide who your book should look.
I.m.h.o. it’s still ridiculous that software like Adobe InDesign isn’t giving any clear feedback on what’s happening. Using fonts shouldn’t be or become anything like guesswork, code editing, or rocket science. Imagine PostScript would work like that, generally requiring all kinds of tweaks and edits to get it right. Then Desktop Publishing would never have revolutionized the printing industry…
Creating ePubs (2 or 3) can’t be compared completely with using PostScript, I agree. But this mere fact gives even more reason to be clear and helpful about any license issues or other problems with fonts.
HI Peter, I don’t see this as an InDesign problem, but more of an ibooks-specific issue. It’s meta info for ibooks only that has to be inserted in the .opf.
InDesign does supply that when fonts are embedded on export; it’s only when they are not embedded that InDesign leaves it out. What i would like to see is an option in the Export to EPUB dialog to include the meta info, so that if I’m spec’ing even generic serif/sans-serif in my own CSS, I can have the iBooks meta included in the .opf and get the results I want.
And, as you mention, EPUB 2/3 can’t be correlated to PostScript. If all Adobe had to do was honor EPUB2/3 standards, life might be more straightforward. Instead, we all have to deal with the different devices and their idiosyncrasies. Adobe wrote PostScript, so could control it. They don’t have much control over how Apple writes software for iBooks, or Amazon for Kindle, etc. Export from InDesign certainly isn’t perfect, and that’s why our communities of support and knowledge-sharing are so important.
Thanks for writing. Come again!
Well, I’m here, again 😉
I DO think it’s an Adobe thing to let InDesign (or any other or new application or tool for that matter) help us creating ePubs (both 2 or 3) that WORK ! And especially ePub 3.0 FXL, which has proven for almost 5 years now that this monster of a standard simply can’t be honored in ALL aspects for ALL devices.
Apple was clever enough to foresee this problem, and choose to let their adapted ePub 3 (called “iBooks”) become an Apple-only file format. And only 5 years later Adobe finally chimes in with InDesign and its initial support for “some readers” (notably iBooks and their own but flawed ADE). If this had not happened, ePub 3 FXL would remain dead in the water.
BTW: there’s nothing wrong with companies cherry-picking each other technologies. Apple and Adobe ignited Desktop Publishing, followed by a slew of other printer manufacturers, based on Adobe’s PostScript. It drove a thriving industry for the past three decades, and the technology was never surpassed by others.
The difference might be that ePub and HTML(5) are standards not “owned” by a company, but if companies base their tools and devices on such a standard and agree to improve it on their behalf, what’s wrong with that ?
Back to the fonts issue and my plea for not raw-editing ePub files: while typing this comment, why do I refrain from using typographical niceties like bold and italics ? Because I, like 99% of of all designers, I hate typing codes. I want to select a text, hit a button, or choose from a popup. Hey, Desktop Publishing replaced the same culprit: type-setting codes and systems went out – user friendly software entered the industry.
Need I say more ?
I rest my case… 😉