InDesign to EPUB to Thorium Reader — bug in TR

[James Gifford—NitroPress]

Another slightly aside issue that anyone who exports to EPUB should know.

I, and many others, prefer Thorium Reader as a clean, standards-driven, nicely "vanilla" reader for EPUB.docs. If it's right in TR, it's good to go.

Except that there's a noxious bug of long standing, which I recently tripped over. Put briefly, Thorium uses a very aggressive font-size 'regularizing' algorithm, designed to get around bad EPUB code using fixed font sizing (px, pt, mm etc.) One side effect is that on some documents, it will force all styles to 1em/rem. The size definition of the style is ignored. The problem has been reported (in GitHub) for almost two years; each ticket is noted and closed. The programmer responsible more or less says he can't find a way to apply the font fix AND respect all author stylesheets, so the issue persists.

The punchline here: the problem seems to apply mostly, if not only to EPUB exported from ID.

I expended quite a bit of effort trying to fix/cure the problem without success and before discovering it was inherent in the reader. It also applies to the browser plug-in EPUBreader, my other go-to proofing tool, which I believe borrows the root Readium code. However, the Calibre, Sigil and Ice Cream readers all present EPUBs (from ID) with size styles respected, so it is a solvable problem... someday.

Just a heads up until the EDRlab folks figure out how to please both masters.

—

[J E L]

Good stuff, thanks @James Gifford—NitroPress. I've been sticking with calibre for the last few years. Most of my book clients only need Kindle and Nook versions with their print editions. InDesign to reflowable EPUB 3.0 viewed in calibre is almost always perfect for Nook. I use the Kindle Previewer 3 (not Kindle Create, lol) for Kindle. Mind you, most of these are text-heavy trade books, but some have illustrations and image sections. In nearly all cases, a print file won't export and automatically look great as an EPUB. This is where I've seen some users having trouble. I make a document copy, minimize styling, and use special tagging specifically for EPUB exporting. Any text-wrapped images have to be broken up. I've learned to group and anchor images and captions on separate pages. The only PITA is if there are changes because now there are two documents to fix! That's why I always like to see the print version in hand before making the EPUB.

[James Gifford—NitroPress]

That Thorium bug is really irritating, because it means I can't recommend it without reservation as the baseline for EPUB proofing. Calibre is good, but I have a well-developed bias against the "e-book mindset" it encapsulates — obsessed with the technical structure, "building" books like a garden wall, and converting every format into every other format. But the reader is an acceptable backstop to Thorium for proofing, at least until the EDR folks decide that egregious fault is worth fixing.

I don't think I've ever sold a book on B&N/Nook and I've stopped uploading both my own and client books there. So a non-issue. (Same for Smashwords, actually.)

But mastering dual-format publication for Kindle is both straightforward and a very valuable technique. For one thing, it means there's one and only one source, so you don't have to keep edits and updates in step across two (or more) source files. Also, since it does involve some grasp of CSS, it means you can do an extended range of things in EPUB/Kindle that are not possible from a straight ID export. You can go either direction for dual-format, but in general I prefer and recommend getting a clean print edition and then using CSS export to refine it into a flawless e-book.

[James Gifford—NitroPress]

An update, August 2024: Thorium Reader has finally received a fairly thorough overhaul and v3.0.0 was released last month (from v2.7.x).

Some of the reader's issue have been fixed, and I commend EDRlabs for working at it, to the point, as I understand it, of hiring one of the original developers to fix and improve the app.

However, the font-sizing bug remains. Some styles will display at a desired font size (unlike before, in which ALL styles were flatted to 1em), but others are still "regularized." In books optimized for Kindle Previewer and Calibre's reader (two slightly different optimizations at the CSS level), the first page title, subtitle, author, publisher, copyright etc. are all varying sizes, as formatted. In Thorium 3, they are all regularized to 1em. No trick of CSS including !important statements will correct this.

For a number of body styles that are formatted to be smaller than 1em body font (footnotes, running aside notes, code snippets, etc.), these are also regularized to 1em, making them larger.

There are many other variations in how Thorium presents these documents optimized for the other two readers, but so far it seems to be normal variation between readers and the styles can be corrected at the CSS level to provide desired results. (And, all in all, I would prefer to optimize EPUB for Thorium and let all other readers, Calibre included, try to catch up.)

So as much as I'd lke to say Thorium is fixed and a good/best choice for general EPUB proofing and reading, I can't. It seems suited only to very simple documents, not a great deal above very plain web page styling, and is faulty in rendering many relatively simple and basic formatting requests.

Here's to v3.1.0, I guess.