Unexpected behaviour with superscripts and subscripts in epub3 compilation.

Posts: 1415
Joined: Wed Mar 18, 2009 12:22 pm
Platform: Mac

Mon Nov 27, 2017 7:41 pm Post

[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
Screenshot 2017-11-27 19.21.10.png (78.54 KiB) Viewed 189 times

* 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
Screenshot 2017-11-27 19.29.49.png (45.11 KiB) Viewed 189 times

Is this expected?

User avatar
Posts: 198
Joined: Wed Nov 22, 2017 2:24 pm
Platform: Mac

Mon Nov 27, 2017 8:11 pm Post

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.

User avatar
Posts: 13
Joined: Tue Nov 21, 2017 11:50 pm
Platform: Mac
Location: Oregon, USA

Tue Nov 28, 2017 12:36 am Post

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:

Code: Select all

<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 <sup> and <sub> 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 <sup> and <sub> but CSS which forces explicit position and size change:

Code: Select all

span.s2 {font-size: 90%; vertical-align: 3.9px}
span.s3 {font-size: 90%; vertical-align: -1.2px}
<p class="p9"><span class="s1">This entire paragraph is Arial font</span><span class="s2">2</span><span class="s1">, but</span><span class="s3">2</span><span class="s1"> with </span><span class="s2">33333</span><span class="s1"> a mixture</span><span class="s2">4444</span><span class="s1"> of </span><span class="s2">444</span><span class="s1">font sizes, font colours and font superscripts. No “styles” are applied.</span></p>

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!

User avatar
Site Admin
Posts: 19198
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall

Wed Dec 13, 2017 6:06 pm Post

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.
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."