Unexpected behaviour with superscripts and subscripts in epub3 compilation.

[I’m assuming we should use this forum now, rather than the old beta-tenderapp one?]

Over on this thread, we’ve been discussing the epub compilation process and how to reflect font sizes.

As part of testing that we came across this behaviour, which seems a little unexpected with superscripts / subscripts.

To reproduce:

  • a ‘no style’ paragraph with superscripts / subscripts entered with Format > Font > Baseline as normal.
  • default compilation : epub3 > E-book, with the default Section Text layout for the text section.
  • no customisation at all.

We get this (every number in the box is actually a superscript or subscript)

Screenshot 2017-11-27 19.21.10.png


  • a superscript or subscript of any length directly behind a word compiles correctly.
  • a superscript or subscript with a space in front of it (with or without one afterwards) fails to compile and looks like normal text.

By comparison a straight default compile to PDF > Paperback gives this, with all superscripts/subscripts coming through properly.
Screenshot 2017-11-27 19.29.49.png

Is this expected?

I think the superscripts and subscripts are faked/relative to their attached words/the baseline.

Unattached, they float and are treated as regular baseline text during ePub 3 compile (unless given a named style).

So I assume the behaviour is expected.

Be interesting to hear from Keith or Ioa.

Since I’m set up looking at epub compilation issues I’m having (regarding code blocks, described in another thread) I decided to have a look at this. For EPUB3 output, I see this:

<p>This entire paragraph is Arial font<sup>2</sup>, but<sub>2</sub> with 33333 a mixture<sup>4444</sup> of 444font sizes, font colours and font superscripts. No “styles” are applied.</p>

You can see that Scrivener 3 does use and but fails to do so superscripts and subscripts not immediately following a printing character. What surprised me was if I generate Kindle KF8 MOBI it works, but doesn’t use and but CSS which forces explicit position and size change:

[code]span.s2 {font-size: 90%; vertical-align: 3.9px}
span.s3 {font-size: 90%; vertical-align: -1.2px}

This entire paragraph is Arial font2, but2 with 33333 a mixture4444 of 444font sizes, font colours and font superscripts. No “styles” are applied.


I was surprised because the issues I’m having show up for both EPUB and MOBI but now its looking like the generators don’t share code!

The reason for this is that, internally, Scrivener’s rich text is converted to MultiMarkdown which is then converted to HTML5. It adds a great deal of custom HTML that MMD wouldn’t otherwise handle, but superscripts and subscripts are all done using MMD, and they have certain rules (such as that they must come straight after text and cannot contain whitespace or punctuation). So, currently, Scrivener only supports superscript and subscript that comes after other text in ebooks.

I think if you install your own MMD V6.x then this should start working (the behaviour seems to have changed since the V3 that is bundled with Scrivener); may depend on whether Keith’s RTF⇨MMD engine uses the single ^ and ~ syntax for conversion?

You can test MMD directly on the command line (use CTRL-D when you’ve finished entering your markup and it will send HTML to stdout).

>  multimarkdown                                    
this is a ^2^ test^444^ to see how ^333^various things~2~ work

<p>this is a <sup>2</sup> test<sup>444</sup> to see how <sup>333</sup>various things<sub>2</sub> work</p>

No, it won’t work because Scrivener’s MMD injection follows the rules whereby it works - it won’t inject ^ when it wouldn’t be converted by MMD. I’ll speak to Ioa about possibly bundling MMD 6 in the future. We have to be careful about what we support and bundle.

All the best,