Spacing discrepancy in two different Scrivener files

The first link is my contact information.

Do I use your email? I’ve never worked through Zoom.

In light of my not being familiar Zoom, trying to work out a Zoom call might not be the best/easiest solution. Could you suggest a fix over this website? The Scrivener problem I’m dealing with is fairly clear, I thought, but if you have any other questions I’m happy to respond.

23 posts were split to a new topic: Preferred forms of tech support

To return to the original matter: there is more than one kind of line spacing, and you might for whatever reason be seeing different kinds in these two bits of text.

Here’s a simple demonstration:

  1. Create a new text item in your binder somewhere, and type in two lines of text.
  2. Use the drop-down in the Format Bar to set the line-height multiplier to “2.0”. This takes the natural height of each line and multiplies it by two, whatever that may mean. If there is a 48pt letter on the line, then the padding itself will be a lot taller than a line with only 12pt text. If you superscript some text so that part of the line is higher than other parts, it will have more padding than other lines. You can already see how this particular tool isn’t a very good one for consistency.
  3. Now use the same dropdown you used before, but this time pick “Other…” at the bottom.
  4. Set the Line height: At least setting to 32 points. As you do that, you’ll see the effect in the background immediately.
  5. Set the Inter-line spacing value to 12 points. Again, it jumps to an even larger amount of padding.

At this point we’re telling the formatting that no line should ever have less than 48pts of height, and on top of that we always want to insert 12pts of padding between lines. Lines might still actually be taller than 60pts (say we insert an image 350pts tall), but they will never be shorter.

And, at this point with a 12pt font, “2.0” essentially means nothing, because that multiplier operates on the actual content request for the line, and 24pts is smaller than our declared minimum of 60pts. We’d only see the effect of the multiplier if the doubled height resulted from content requesting more than 30pts of height, like an image or even a large heading.

Close this panel with the settings we’ve given it, and have a look at the format bar. And now you can see how two pieces of text with “the same formatting” actually don’t. This tool is flawed in that it only shows one setting out of potentially half a dozen.

We can also see how this tool doesn’t change other settings as well. Try changing it to “1.0”. Nothing happens! Nor should it, because again we’ve declared we want at least 60pts of padding.

At any rate, theory aside, here’s what you want to do, in order:

  1. Go into Project ▸ Project Settings... in the Formatting tab. Just check to make sure the Use different default formatting for new documents in this project checkbox is set. If it is, skip over the next step. If not, just close the panel without changes.

    Optional: if 2.0 is a “this project” kind of decision and not something you want all of the time in all of your projects, then do consider checking this box and completing the steps in this panel, leaving your global application defaults alone.

  2. Close the panel if necessary, and open Preferences: Editing: Formatting.

  3. Note the line-height tool in the format bar for the sample text. Use it to open the “Other…” option. Set the line height multiple to what you want (2.0), and make sure these other settings we experimented with are zero-ed out, and close the panel.

Okay, now your defaults (whether global or project-specific) are good (or you’ve at least verified they are). Now you can go to this section that has odd formatting and use the Documents ▸ Convert ▸ Text to Default Formatting.... As for the settings in here, you probably want all of the checkboxes off, but use your best judgement. If you have centred text and want it to stay that way for example, check the Alignment checkbox.

That should be all you need, and that command is the safest way to clean up formatting because it has those optional exclusions, and as well takes care to keep inline formatting intact.

There are other, more scorched earth ways of stripping out formatting, like cutting the entire section out of the binder item, looking at something else and returning (to clear the underlying RTF file), and then using Edit ▸ Paste and Match Style. That will treat the text as plain-text, stripping out italics, highlights, styles and everything. Sometimes that is what you want, though.

And it sounds like you’ll have a better time going forward as well, as it sounds like you’ve been manually battling your default settings all along, since they were 1.2 and you want 2.0.

1 Like

I do wonder, considering this layering of formatting confusion pops up constantly on the forums, whether some sort of “Show applied formatting” popup in V4.future of Scrivener[1] could make defining these problems easier (for end-users and those who volunteer their time of these forums trying to help!). I vaguely remember this “Reveal formatting” was the thing that Wordperfect users used to constantly harp on about as the reason their WP was better than anything else at the time…


[1] assuming V4 still uses RTF of course, KB remains in stealth mode no doubt pondering the existential or trivial changes coming our way :stuck_out_tongue_winking_eye:

Oh I never understood why everyone championed “no codes” back when that became The Thing. So much nonsense and hair pulling has been caused by simply being completely unable to see what is going on underneath the WYSIWYG portrayal. It always smelled like marketing-driven “Simpler Is Always Better” junk to me. It’s not, but it does often sell better.

In Scrivener there are at least not too many palettes and tabs to scour through!

That aside, this problem (or ones like it) is a special case of confusion, and I do entirely fault the macOS text engine’s UI. In most cases it is not useful to have a line-height multiplier if you’re using other line-height models, and in fact some word processors don’t even let you set multiple potentially conflicting models like you can here. The Windows version for instance does not have this problem, because if you wish to set the line model to At least, then to do so you must switch off Multiple—same as in LibreOffice.

But for whatever reason Apple thought it would be a good idea to not only leave the multiplier setting mostly non-functional beneath the total calculated line height, but the dominant and only feedback for formatting in the format bar. :woman_shrugging:

4 Likes

I split off twenty-three comments about whether or not this or that form of support is more effective, to another thread. Honestly if someone makes their own personal preferences known, as you did, that should be all anyone needs to know, in my humble opinion.

Meanwhile, I remain interested in the original problem: did the above advice help you pinpoint the source of the differences between texts? Or are we looking at some other kind of problem do you think?

3 Likes

Thank you for your in-depth response. I have the problem in hand now. I greatly appreciate the time and thought you put into this question.