I think it’s going to be hard for me to view a page that doesn’t quite “look” right and just leave it alone til its time to print it out. So this is the problem…I just put a superscript, the number 1, next to the appropriate word, and it made the whole line move down a little, probably to accomodate the number being somewhat above the word. So will it print out looking like the line spacings are now unequal or will it print out making the lines look like they have the same spacing between them, regardless of what they look like to me now?
What you see is what you get, most of the time. I recommend increasing your line spacing to accommodate baseline shifts. This is part of the reason why typesetters space lines out more than a typically default word processor setting. The other reason is readability. You will need to use precise line height measurements as opposed to the relative measurements. In the spacing drop-down, “Spacing…” at the bottom, and instead of Line height multiple, which is the easiest to use, you’ll need to set up a Line height of exactly a certain number of points, depending upon your working font size. You can use math to figure this out, or just play around with it while a superscript is visible. Tabbing between fields will update the display.
For me, working at 12pt, a precise line-height of 18pt was enough to accommodate the superscript. Note that with this setting, you won’t be able to change your font size as easily. That is why using the multiple is easier, but the multiplier adds space in addition to baseline shifts, rather than ignoring them.
Let me ask this, if I just leave things alone and let it look funny for now, when I export the project to a Word Processing program like Nisus, for example, will the number “1” superscript look like it ordinarily does in a book, very small and slightly raised, or will it look like it does in Scrivener - a full-sized number 1 taking up one full line above the text it’s in?
That surely depends upon the word processor. Mellel, for instance, handles super-scripts just fine without blowing out line separation. I would be surprised if Nisus could not do likewise, but you might as well test on a file to see.
Thanks Amber, I’ll try it with whichever program I buy, which is going to be a while (or try it when I try those programs out). I wonder if I shouldn’t add a request to make the line spacing normal with footnote numbers, in the next update?
Stuff like that is handled by the core OS X text system, and making little visual tweaks like that has always been something on the “Scrivener is not a word processor” list, though you never know. It might be an easy fix.
This an ancient thread but I am having the same problem, super-script disrupting line spacing and am wondering if after all these years it has been fixed?
If I compile to PDF line spacing is disrupted. If I compile to RTF Word takes care of line spacing. But it would be nice if Scrivener could deal with this eyesore other than to turn off super-scripts.
I use Scrivener as my main writing tool and rarely open Word hence the desire for control of the font size of super and sub scripts like Word provides. It is just more aesthetically pleasing and makes for a more harmonious integrated writing environment.
The method I described in my first response is still relevant. Using exact line spacing instead of multipliers is the way to go.
You can test for yourself whether Apple has adjusted the behaviour, using TextEdit. I doubt they ever will though.
RTF is a proprietary file format developed by Microsoft. It has not been updated since 2008. While most word processors can open RTF files, compatibility is poor, even with post-2007 versions of Word.
Some developers utilise the 2008 RTF standards to produce tools that can read or write RTF files, even though MS has warned that “the RTF file format is no longer enhanced to include new features and functionality (…) RTF does not reliably preserve the formatting, layout, or other features of the document.”
RTF is unreliable, flawed, insecure, and obsolete. The Library of Congress, for example, recommends using XML-based markup formats instead.
As RTF has been abandoned, there is no point in Apple bothering to sort out the problems created by MS.
RTF, an adjunct to TextEdit, was originally provided to give Apple users a free-but-basic MS-compatible word processor in the days before Pages was bundled as a free fully fledged word processor. As such, because Pages now fulfils the free word-processor role in macOS and iOS, Apple no longer needs to provide an RTF reader or writer in TextEdit … or to any apps that use the macOS text system.
TextEdit, with support for RTF, was never designed to be used for anything beyond producing simple standalone documents.
Scrivener, which uses RTF at its core, was released in 2007, just as MS abandoned RTF. It has continued to use RTF since. Despite what some users might claim on the forum, RTF is a WYSIWYG word-processing tool, albeit a very poor one. Scrivener definitely can, but doesn’t solely, produce WYSIWYG documents, complete with RTF rendering glitches.
For blindingly obvious reasons, Apple is drawing back from RTF. While it may provide a legacy tool in Pages to read RTF files, the support to write RTF files will end at some point in the not too distant future: computers and mobile devices have moved on too much to carry on sustaining old and insecure code.
So the issue here isn’t down to Apple having to fix MS’s mistakes. The formatting of superscript is poor in RTF, and it is never going to change. Some developers write their own code to correct the superscript problem (and other RTF problems), but L&L and Apple are never going to do that.
Thankfully, we are looking at the endgame for RTF. This will obviously impact on any apps that still rely on it as a writing tool.
Nonsense. Nobody has claimed anything of the sort – what we do remind people is that Scrivener was never designed to be a WYSIWYG word processor. It is a writing tool that inherently separates your writing environment from the final product that you produce through the Compile process. I can use 67-point MS Comic Sans with 3.14159 line spacing in my editor for everything and with the simple change of which compile format I’ve selected, produce conventional manuscript format document that looks nothing like what my text in the editor looks like, without Scrivener having changed the text in the editor. That is most definitely nothing like WYSIWYG.
RTF is file format. There is nothing inherently WYSIWYG about file formats. Don’t conflate the file format with the tools that manipulate those file formats.
RTF may well be a crappy file format, but it’s one that Apple already paid the licensing for, and it’s the one they support in their Textkit APIs in MacOS. Since Scrivener was originally built on top of the libraries provided by Apple, it continues to make sense to use it as long as Apple (and now Qt) continue to support it.
For some unexplained reason it now works in Scrivener. The superscripts appear in a smaller font and do not disturb the line spacing in Scrivener.
Perhaps it was because I toggled “superscript ordinals” off and then back on in preferences. That is all that I did. But now all is well and I am pleased with the aesthetics.
Didn’t know people were so passionate about RTF
I use RTF because it is readable by all Word processors. (I had bad experience in the past.) Also I don’t do anything fancy in MSword so never had to worry about possible formatting loss and such.
Actually, contrary to most people’s beliefs, the .RTF file format itself is much stabler than the standard MSWord formats. Also it is a lot simpler to parse, and has less reflow problems. In extreme cases, you could even open up the document as a .txt and still copy out the raw info!
Other than that, it (and most formats) could never be a true WYSIWYG format, as it is interpreted by reader & editor apps with slightly differring standards and calculating errors.
OTOH, as it is truly crossplatform compatible (PC/MAC/LINUX) and not necessarily proprietary, it is perfect for distributing raw text with minimal Font, Fontsize, (etc…) choices embedded, and will offer less issues compared to eg Word Files (different for every platform, version of Word, or Font settings) when imported into eg Adobe InDesign, Affinity Publisher or other lay out apps.
I will continue to use it, until a decent Mark Up language with actual design options becomes feasible, as it is an excellent communication file format between designers, writers, editors etc…
It will let a non-technical person add what they feel should be “in bold”. Style Options in Word are possible, but are rarely well used and thus can better be avoided altogether.
(Any instability is mostly due to reader/editor apps being poorly written (as most “pure” .rtf writers are often barely more than a sandbox app with a .rtf/.txt API inserted), and should be offset to the instability of “hidden information” entering a design document because a .doc / .docx file smuggled in some obscure new feature from Word v2022.234.948.123b)
I’d rather have TextEdit crash because it was poorly written, than have InDesign refuse to spit out a 1.5 GB PDF file, only because MicroSoft suddenly decided it would add yet another “invisible character” into its document model.