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.
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.
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.
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?
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.
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!
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.
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!
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.
Yay! This bug is now fixed in the recent Windows v3.1.6 release. Only took 4 years… From the release notes:
“Fixed a bug that temporarily removed the editor margins after rolling back a snapshot, causing text to go directly to the edges of the editor.”
