How to do type and exponent like for e=mc squared?

How do you type an exponent?

It’s not English, but I’m sure you’ll find it.

surely you jest
is this serious?

Scrivener → Edit → Emoji & Symbols, or Fn E.

Type “superscript” and pick your number (works also with “subscript” for stuff like H₂O).

1 Like

I use a lot of superscript text. IIRC I just customized my formatting toolbar by adding the button to the toolbar. (I did that years ago in v1, I assume it’s still an option.)

I have a related question.

That said, can anyone tell me if there are any particular caveats regarding compiling into various formats/compile styles/section types so that the superscript doesn’t ever get over-ridden in compile?

If you type it (instead of simulating it with formatting), it should survive. The formatting probably doesn’t work if you tell the Compiler to overwrite all formatting. I guess. :thinking: Can’t hurt to use styles for such cases, even if they don’t carry any actual formatting.

1 Like

Thanks, but it just does not work. If I go to Scrivener>Edit>Emoji & Symbols there is no search bar

Hmmm. Does the Emoji window look like this?

In this case there’s a smaller search bar (next to the green circle) or you can just restore the “compact view” with this button.

You could also use replacements, either the macOS built-in, or other tools; I prefer Alfred. In Scrivener I write !e5[space] and ×10⁻⁵ is entered with the cursor before ⁻ so I can delete the superscript - if needed, i use different replacements for different exponents and sub/superscripts.

For nerds you can add the hex input keyboard and enter the hex value, but the unicode ranges for super and subscript are not really logical…

I always use real unicode characters where I can, it means there can be no problem later. When simulated using RTF styles, it then depends on your compile workflow, or lets say you copy and paste text to some other place that doesn’t support RTF etc.


Not using real characters, and using baseline adjustments and font size tweaks, also leads to an endless stream of duplicate threads like this one.

Even for text engines where the above isn’t a problem and it overrides the literal definition of a line-height multiplier for those special cases, I still classify the whole word processor baseline approach somewhere in the same neighbourhood as Word’s “bold” and “italic” buttons, which always work, even if the font does not have those variants. In that case it does so by adding more pixels around them, or crudely skewing the letters, respectively. It’s a brute force approach that’s maybe acceptable for office memos and personal letters, but ideally has no business anywhere near a book, paper or otherwise professional document.