Unexpected behaviour with superscripts and subscripts in epub3 compilation.

br
brookter
Posts: 1713
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 1174 times



I.e.:
* 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 1174 times


Is this expected?

User avatar
Bridey
Posts: 390
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
thomasalmy
Posts: 22
Joined: Tue Nov 21, 2017 11:50 pm
Platform: Mac
Location: Oregon, USA
Contact:

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!

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

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."

User avatar
nontroppo
Posts: 1035
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Tue Dec 19, 2017 2:00 am Post

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).

Code: Select all

>  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>


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

Wed Dec 20, 2017 5:21 pm Post

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