What my complain is about is the fact that with a document that’s over a screen long, pgdn drops TO THE END OF THE DOCUMENT. I can live with it being stopped at the boundary, but going 20-30-40 pages down with one accidental pgdown is very, very annoying.
Yes, that is how I wrote the bug report. I don’t think there is a misunderstanding here.
The conversation moved on, to other things, including my describing why it is challenging to fix at a higher level. Perhaps this was confused with my saying we shouldn’t fix it, or that I think it isn’t as bad as it is? I don’t know.
So the result is, I am forced to create what you’d probably call ‘proofing copy’ and compile the scenes into a doc, then use Libre Office to do the review, because LO does pg-dn correctly and I can have a nice, no-fuss experience.
Ah okay, I guess with my preference for using PDF to proof with, I’d never really thought about it like that, to put an editable RTF file into the binder for proofing, let alone splitting it up into small sections so that Scrivenings mode is used, and we encounter the bug again. The idea was to try and avoid it, while staying in Scrivener, rather than go out of the way to recreate its conditions.
But for anyone else that doesn’t mind page by page PDF proofing, to a expand a little on what I briefly glossed over in that paragraph, here are some tips and tricks:
- I extensively use the shortcuts for
Navigate ▸ Editor ▸ Other Editor ▸ Next|Prev Page
, which flips to the next whole page of the PDF, once I’m ready to advance, but since that isn’t Scrivenings view, and thus does not have this bug, the normal “remote pgdn” also works in a fashion that is fairly typical for PDF paging, too. (Note I changed the defaults, which I found arcane and hard to use. Normal Other-PgUp/Down are Alt+Up/Down
, and Other-Next/Prev Page are Shift+PgUp/Dn
).
- You can import the PDF with
File ▸ Import ▸ Research Files as Shortcuts
, so that compiling in place will update the copy you are proofing from, right in the other editor (and it also means you don’t bloat the project with another whole copy of the work). And with the “other editor” commands you can read through while working in the active editor split.
- As mentioned briefly before, the Insert links back to Scrivener in each section compile option can make it very easy to get to a specific spot, particularly if you set how clicked links use the “Other Editor” (back to the working split from the proofing split), in Behaviors: Document Links. Every chunk of text produces a link back to it the binder item itself, that works from everywhere. When used outside of Scrivener it will even launch Scrivener and load the project if necessary, but when working this way, it merely loads the section in the other split so we can fix the problem.
So all editing is being done in Scrivener, against a static copy I compiled for review in a dual-split interface.
For me anyway, I find it much easier to find typos and awkward phrases if I completely change how the text looks, anyway. So for myself, I am not really even going out of the way here as I would want to work like this no matter what. I’m just making use of various Scrivener features to make that way of working so much better (than for example using a stand-alone PDF reader and juggling Alt-Tab and searching for phrases to find binder sections, and other inefficiencies).