Fonts Without a Point (2)
And here we are with another post on the subject of fonts. Just as it was clear would happen. What can you do - for most publishers, it's easiest to export straight out of InDesign without stopping to think that maybe not everything is perfect in Adobe's kingdom.
The fact is simple - most fonts are protected by copyright. And so, if you want to be sure the reader will read the book in your very special font (Frank Ruehl again??), you'd better supply the font itself along with the book to the reading app.
But what's the point of supplying a font if it's encoded and protected?? There isn't much logic in that, right? InDesign will warn you, in very small letters, that your font is protected, but it won't stop you from exporting it into the book - in an encoded format...
What's the harm?
The harm can be minor - such as the font not loading and a different, standard font being used in the reading app. But sometimes, when the reading app does insist on trying to use the book's font (if you asked it to), the problem may cause an incorrect calculation of the font size - and from there to an incorrect calculation of the page numbers in the chapter, the creation of blank pages or missing pages, and other display problems that make reading harder.
Therefore, it's always worth making sure you have the open, non-encoded version of the font you're using - and embedding that version into the digital book you're creating. (Yes, yes, manually. There's no magic button in InDesign, and there won't be.)
Tracking down the fault
It's very easy to spot the problem of an encoded font - just open the book's pages for reading in Chrome, which leads the market when it comes to proper display formatting - and right there, in the error console, you'll be able to see Chrome warning that it can't read the font because of a... you guessed it - encoding problem! (See the attached image.)