I can usually find the error by pruning the text until it goes away and then saying a few incantations, but the current chapter has been a nightmare. The full thing fails on the first page; if I copy the chapter into a new doc and then start pruning it seems to fail at different places. Sometimes superscripts or subscripts in the first row of a table (but not in the rows below) makes it barf. In the attached piece it fails at a subscript, but in the full chapter, as noted above, it fails earlier. I have zapped gremlins.
This seems random and it did not used to happen. The pink error box does not give any guidance as to what’s wrong.
“Let’s use the system in Figure 5.<$n:figure:mshbt> to predict what will happen during hydration of a MOR harzburgite, represented by the blue dot in Figure 5.<$n:figure:550350>. The original rock is anhydrous and therefore plots on the MgO-SiO2 sideline.”
“MgO-SiO2” compiles as: MgO-SiO2
This fails. If we edit the XHTML file to switch the closing around as below, the compile works and loads as an ePub: MgO-SiO2
I don’t know why the error occurs, but a post-compile edit can make it work.
Interesting detective work, thank you. I have done a bit of experimenting and found that subscripts + bold, regardless of the order in which they are applied, fail. I will report this as a bug. This probably explains why subscripts in table headers fail, but subscripts in the body don’t.
Welcome. And post-editing can fix things as a last-resort workaround.
Does look like a bug, as you say, with bold and subscript or superscript combined. Have posted a bug report. Will be interesting to see if there is a different solution.
The problem with that is that the display font on the e-reader is chosen by the reader, not the author, so it may well not work, whereas using strong will work as ePub is basically html at heart.
Yeah, I second the caution about using “medium” weight fonts and such, it may work on your computer, depending on the viewer, but it’s very unlikely that your readers will have this same font on their device.
I’ve tested the problem out a bit, and have found that Styles work well here. You can save your bold formatting to a named character style and then mark each of these texts with the style. All around that’s probably a better way of going about things than using font settings. For one thing if you change your mind about the look in a year, it’s one simple adjustment rather than hundreds.
To help with converting to a style-based workflow, the Edit ▸ Select ▸ Select Similar Formatting menu command will help in that it should select most if not all of these examples, meaning you can batch apply the style with one click. Pay attention to existing super/sub-scripting though, as character styles store all settings, including a default baseline. You’ll have to add these back to the text after applying the style, unfortunately.
Yeah it’s a bug, and it will be fixed in the next update.
It’s different from the regular HTML output, which is a direct conversion from RTF to HTML using the Mac’s conversion engine (pretty much the same thing you’d get if you load an RTF in TextEdit and save as HTML). With ePub we use MultiMarkdown to generate the HTML because ePub 3 requires HTML 5, which the Mac doesn’t support. So conversion to ePub is complicated by converting rich text to Markdown, a pure plain-text workflow, with select rich text conversions applied on top of it where MMD can’t do a thing specifically. Somewhere in that mix-up the syntax for sub/superscripting gets placed in the wrong spot.
To which format are you referring to? I tried the HTML output, but that doesn’t use modern elements, and the ordering is balanced correctly:
...The original rock is anhydrous and therefore plots on the <b>MgO-SiO<sub>2</sub></b> sideline....
The only other way I can reproduce this is by using the same tech used to generate an ePub: compile to MMD→HTML, with the full rich text conversion option enabled. That’s not identical to ePub, but pretty close.
I meant that the OP’s sample file compiles to other formats without error (such as RTF, docx, PDF, and HTML), so the issue seemed to be solely with ePub and how it compiles the mix of bold and superscript / subscript, rather than anything any user had done / could do.
