Epub file displaying numbers strangely after export from InDesign

[defaultbpgkg3n7ogjs]

Please see screenshots attached. The font is currently Garamond and I have tried changing to Caslon but the same issues happen. Any idea what could be causing this? It doesn't happen to every number and I can't seem to find any logical pattern as to the cause. Thank you!

[James Gifford—NitroPress]

Is this a reflowable EPUB?

Two things. First, it's poor practice to specify/embed fonts in EPUB. It adds nothing to most books, and it's a somewhat fragile process given that most readers insist on managing the display according to their own rules and the preferences of the user. It also bloats the file size.

Second, what reader are you using? They vary considerably and almost everything about how EPUBs display and read is dependent on the reader. I suggest using the fairly vanilla, standards-based Thorium or Calibre readers for proofing EPUBs. Most of the others (Apple, Kindle, Adobe, etc.) are not very standard and don't always present EPUB books properly.

[defaultbpgkg3n7ogjs]

Thank you, yes it's reflowable. I'm viewing it via iBooks but my client also sees these numbers displaying incorrectly on their Kindle. I have just tried to replace the font with Times New Roman and I got these display errors so I believe it must be how some of the numerals are formatted in the InDesign document, though I can't see what's different about them.

[James Gifford—NitroPress]

Neither iBooks nor Kindle are standard readers. It's often necessary to create EPUBs that work properly on each, but they will not be standard files with standard settings. (In the case of Kindle especially, side-loading EPUBs onto them is a lousy process with very poor and unpredictable results.)

Start by not embedding any fonts. It's a checkbox in the EPUB export menu. The problem is coming from conflicts between that local font and what the readers want to use, so eliminate the conflict by not providing the local font.

[defaultbpgkg3n7ogjs]

Funnily enough even when I unembed the fonts I still get the same issue. But I've managed to fix the problem by replacing them with numbers that didn't show an error and retyping the correct number – time-consuming but at least my client has the file now.

[James Gifford—NitroPress]

Specifying fonts is one problem, embedding them is a second... but oftentimes not embedding them effectively bypasses the spec problem. The problem might have persisted because you spec'ed fonts that most systems would have or map. For giggles, change the font to something oddball in your list and export without embedding. That would normally force the reader to use its default font and mapping, without trying to accommodate a defined font.

[Milo Milinsky]

I had this issue come up for the first time on 8/7/24. Tried all the recomendations here and still no luck. I even cleand up the text in question and saved a new .rtf file and re-imported the text (This was only happening on my copyright page.) Still no luck. Then, as my running body text was acting just fine I tried tagging the Copyright text with my Body Text tag and Kaboom all is well. So, in my case, I'd say the Copyright text tag became corrupt.

[James Gifford—NitroPress]

I don't think I've ever had a case of an individual style becoming corrupt, but it's possible. My forensic chain on this would be to look at all the settings of the style, especially back up through any chain of parent styles, and look for something that was broken or badly set somewhere in that line.

But then again, if a style was giving me inexplicable problems, deleting it and rebuilding from the base BODY font has been a standard practice for a long time. So glad you discovered it and benefited!

[defaultbpgkg3n7ogjs]

I actually found the issue. The numbers were displaying as Arabic so I selected all the text and changed the Language to English in the Character panel. Voila. 

[James Gifford—NitroPress]

That's almost exactly what I meant — some small setting, somewhere, buried, forgotten or inherited from the wrong style hierarchy. After all, if it were simple and obvious, we'd catch it right away. 🙂