Snapshots and margins help

Every time I try to roll back a snapshot it changes the margins of the document. Is anyone else having this problem, and if so what are some solutions or workarounds?

I was going to post some screenshots, but for whatever reason I can’t embed images in forum posts. The text is 40 points away from the left and right sides of the page, but once the snapshot is rolled back the text is pressed up against both sides of the page with no space in between. My zoom is at 100%.

Any assistance would be greatly appreciated. So far, ctrl + 0 has done absolutely nothing, and changing the margins from the Options menu also hasn’t been successful.

1 Like

This is a known display bug that tends to hang around until the project is reloaded. It has nothing to do with the formatting of the document (Scrivener doesn’t even apply margins to text while you’re editing anyway), so it’s entirely safe to ignore it when it happens.

But, if you want to clear it without reloading the project, just go into File ▸ Options..., under Appearance: Main Editor, and simply tweak the editor margin settings by a pixel.

2 Likes

Thank you very much!

If I take a snapshot, edit the WIP and later decide I want to roll back to the original by clicking the Roll Back button, the rolled back text is misaligned in the editor.

Original

Roll Back of Original - See left margin and top of display.

I first noticed it while working in version 3.1.2 and it still persists.

The quick fix for a user is to close the project and reopen it and everything is neatly aligned again.

I’ve tested over multiple projects.

1 Like

For snapshots using the rollback feature removes the margins. Changing he msrgin settings or restarting Scrivener puts it back to normal, but is there any permanent fix for this?

If there is one, I’d like to know.
I’ve yet to find one.

You can also duplicate the document and ditch the original.
But that is bad if you use links. (Or so I would think.)
I usually just restart Scrivener.

As noted above, there is a way of a avoiding a full reload:

It’s a bit, but easier than temporarily turning backups off, reloading, and then turning them back on, to avoid spamming backups.

As for a permanent solution, well if one can tolerate the mode (and it’s limitations such as no Scrivenings mode), Page View is not impacted by it. Interestingly enough, Scrivenings mode is also immune, but it doesn’t actually fix the drawing error for single-text view.

1 Like

I just had an idea:
One, knowing this, could opt to not use the rollback function and rather do his/her own rollback manually:

Click in the text area of the snapshot you wish to rollback to. Ctrl-A, Ctrl-C.

Click the “+” sign, that’ll take a snapshot of the document as it currently is. (Optional.)

Click in the editor, Ctrl-A, Ctrl-V.

There you go. Margins preserved.

3 Likes

I definitely like Page View for this. Thanks!

Bug report for v3.1.4.0 (1918386) 64-bit - 01 Feb 2023 :

When rolling back a snapshot the main editor’s left/right margins are being set to zero px just for that snapshot. Other scenes/editor frames are fine. The behaviour is (annoyingly) consistent, reproducible and still persists when flipping into another scene using a binder selection then clicking back.

The temporary fix I’m using is: Go into application options and set the Editor appearance L/R margins to 0px, apply, then reset back to 20px. Then the editor for that rolled back scene behaves normally. Took me a while to figure out what was going on!

Hi.

A quicker approach is to copy paste the snapshot’s content in your editor.

Snapshot → Ctrl-A Ctrl-C

(Take a snapshot of your editor now if you were going to click yes in the rollback popup.)

Editor → Ctrl-A Ctrl-V
. . . . . . . . .

That will preserve the margins.

You may also simply close and relaunch Scrivener. It would still be more convenient than tweaking (x2) the options.

Thanks, but four keyboard combo actions and two mouse clicks isn’t quicker than clicking the “roll back” button. A relaunch is worse. The scratchpad and reference windows then disappear and need re-opening. Would much prefer the bug to be fixed. Wasn’t there with the prior 3 version.

No, but it is quicker than going in the options.

Yes, it’d be better for the bug to be fixed, I can’t disagree.

It has been present for a good while. Perhaps you just haven’t noticed it then.

Hi @AmberV . Sorry for reposting a known bug - didn’t see the initial report from 18 mths ago. Oddly, the problem only started for me recently and I accept Scriv app updates regularly.
At least I found the right quick fix! Hopefully v1.5 will have a permanent fix…

No worries! I don’t think I noted it above, but there are cases where the problem would not be as obvious. For example if you used the default fixed width editor option and tend to keep the overall editor fairly wide, than losing the 12 or whatever pixels of padding between a (by default) white on white border is something you’d barely notice. It’s a lot more obvious and annoying when the editor is narrower than the fixed width setting because then the text runs up right to the edge of the editor. So that’s something to consider, keeping your editor a little wider than the fixed width value, and using the same colour for the fixed with background and editor background, may mean not having to bother with any other workarounds.

I normally run a multi-pane session in Scrivener, so it was immediately obvious when the problem happened, as the text butted right up against the pane’s edge and the cursor couldn’t be moved to line start with the mouse. But thanks for the info!

1 Like

See my sample above. That’s fixed width, not so?

That’s the opposite of fixed width, from what I can tell, it’s variable, in that the text gets wider and wider along with the window (or the constraints within it, like whether the inspector is open). A fixed line width tends to look more like this:

One side exhibits the bug, the other does not. As you can see, it does not really matter which is which. There are only minor word wrapping differences.

1 Like