Editor freezes for minutes after a compile to PDF

Hi, I’m running Scrivener 3.0.3 on a MacBook (High Sierra). I have noted the following: whenever I compile my work to PDF, then after the compile has completed the spinning ball consistently appears for about five minutes, and I cannot make any edits during that time. When I perform a “sample process” in Activity Monitor, I notice that the CPU is used for a full 100% by the spelling checker (NSTextCheckingOperation). This does not occur when I compile to anything but PDF (so, compiling to RTF, doc, epub does not trigger this behaviour).
Thanks for any suggestions you may have.

That’s a strange one! Have you tested to see if turning off spell check in the project (Edit ▸ Spelling and Grammar ▸ Check Spelling While Typing) prior to compiling makes any difference?

I just tested this, and it does not matter if this flag is set or not, it keeps going through this minutes-long spell checking routine after compilation. If it helps I can send you the process sample log.

It might help. You can send it via PM here, or to our support address. In the latter case, make sure to note down this thread URL so that whoever gets it can forward it to me.

Please find attached three representative process sample dump files.
Sample of Scrivener 3.txt (82.2 KB)
Sample of Scrivener 2.txt (81.7 KB)
Sample of Scrivener 1.txt (80.3 KB)

You mentioned before that compiling to anything other than PDF avoids the problem, does this include using the “Print” compile output, including the use of that feature to save a PDF? There are some significant differences between the two in terms of what Scrivener does—it takes a more hands on approach to layout with the dedicated PDF—some things in there might involve additional processing time. Although we would expect all of that processing to occur before the PDF is written to the disk, and before the compile dialogue closes, maybe something unintended is happening and causing processing to continue after it should be all done.

A problem like that might very well be project-specific. I wonder if you create a sample project that was roughly the same size but consistented of very simple settings (just a raw word count is what I’m thinking here, maybe paste 1,000 plain-text words into a new blank project’s starter document and then duplicate that document in the binder until you have about the same), and compile that to PDF using at first bog standard compile settings, and then next export/import your compile settings from this other project, does that reveal any variation?

It also happens when compiling for Print and saving as PDF (or as PS).

I also tried to create a simple project as you suggested, and then the problem does not occur.

I tried it with my other projects, and the problem occurs for each one of them, to an extent determined by the project’s size. For a 27K word project, it only lasted 10 seconds; for a 116K word project, it lasted almost 7 minutes.

Now I have to mention that all my former projects were created in Scrivener V2 and have been automatically converted to V3. Maybe this has something to do with it?

A very long shot, but possibly similar to this?

literatureandlatte.com/foru … 29#p270129

Thanks for the suggestion, Jo, but, no, I don’t do bullets (I mean bullet points :wink: )

Fair enough. Was hoping … just in case.

Best.

Thanks for checking these things.

Although I would hesitate to rule anything out at this stage, it doesn’t seem to be that a simple case of starting with a v2 project (created much in the same way I described the earlier test, to amass 50k words), updating it to v3 and compiling to PDF results in any kind of slowdown post-compile.

One way to test would be to create a new blank test project, and use the File ▸ Import ▸ Scrivener Project… command to bring in the content of one of your projects. Move the draft folder contents into the right place, and see if the problem persists. I’d stress this suggestion is meant in a purely diagnostic sense—we’d want to use it to figure out what is going on rather than suggest you take this step (as it can be somewhat lossy in terms of settings and metadata). What this would test is whether or not there is content causing the problem, or if it is problem in the internal architecture of the project format itself.

I just did what you suggested: create a blank project and import my content. Same thing, the problem persists. :neutral_face:

I also noted something that really baffles me. To be able to standardise measurements, I deleted all but one chapter and then duplicated it a number of times. I then performed some rough time measurements and it turns out that the CPU time spent post-compile is quadratic in the number of chapters (i.e. the time quadruples as the word count doubles), not linear as would be expected from an editor. You’d expect this kind of behaviour if it was doing a quick-and-dirty word sort for example.

Aha! After a substantial amount of trial and error:
the problem goes away entirely if I remove all apostrophes and quotes (’) from the text.
Most peculiar and, of course, rather annoying. :question:

Uh, wow, that was an unexpected cause. Okay, so working on that observation, if you can take a 1,500 word document from this original project with typographic punctuation in it, duplicate that up to 50k or so in a test project, does the problem reproduce? If so, we could probably get it to happen on our end as well if you send in a sample like that.

Yes, that is indeed what happens. I’m sending you two test cases, one with quotation marks/apostrophes and one without. The former uses 1 minute of CPU time post-compile, the latter nothing.
Test2.scriv.zip (330 KB)Test2noQuotes.scriv.zip (330 KB)

FWIW, both of the sample projects compile without delay or issue using Scrivener 3.0.3 on a MacBook Pro running Mojave beta.

Thanks! Okay, I’ve switched over to my 10.13 test install, since I use 10.12 on a daily basis and was having no luck reproducing the problem with the sample project. It’s been a while since I’ve looked at that install, so it is a few minor points behind (10.13.3). I’m in the process of downloading the update (it’s going to be a good long while as my ’net is slow), so I’ll be better able to test that aspect of your configuration. At the moment, with 10.13.3, I get instantaneous access to the project after compiling.

I’ve looked over the content and nothing strikes me as being particularly odd about it. I wondered at first if perhaps you were using unusual multibyte quotation punctuation, but it appears to all be standard, even ASCII-level simple. Clearly there is something else at bay, despite this being the trigger on your system. If straight foot/inch marks in text files caused this problem so simply we’d be hearing quite a lot about it!

Meanwhile I thought of a few things to ask, and try:

  • Do you use the option to load the PDF in a viewer after it is compiled, and if so which viewer do you use?
  • And along with the above: what happens if you switch that option off, or use Preview/Skim (those are two I tested).
  • After the internal compile process is complete, you should see a “Processing PDF” alert, with a progress bar that counts up by page. This is as far as I know a part of macOS generating the PDF, during which Scrivener must wait until it is done. A long document may indeed take a while to collate, and if for some reason this dialogue is obscured or not showing, then it might lead one to believe the software is unresponsive.

When you get a chance, try a safe boot with all peripherals but the necessary input devices unplugged. It will be by nature slow and awkward to work within, especially if you have a Retina screen, but even so with these two test projects there should be a noticeable difference between the two. Or if not—if in Safe Mode you are cleanly returned to the project that reproduces the slow-down with no ado, then we might be able to narrow this down to a software conflict of some sort.

Your next step would be to boot back normally, and then hold down the Shift key during the log in process to your account (after typing in your password). This inhibits startup software from launching, and so the same test should then be run with nothing but Finder and Scrivener running. If that proceeds without problems, then you’ll need to audit the background utilities and software you use on a regular basis, as well as attaching devices and mounting network drives you might use.

Meanwhile I’ll continue downloading Apple’s 2.6gb (!?) of bug fixes. :wink:

Thanks ever so much for your continued efforts!
Concerning your suggestions:
I don’t automatically load the PDF. The problem persists even when I have quit Acrobat Reader entirely.
I do see the alert box you mentioned (It’s called “Save” I think?) and I see the pages counting, and rather quickly at that. It takes much, much less than the post-compile wait.
The problem persists in safe-mode, and also in normal mode without loading startup software.

I’m now going to try this on my son’s MacBook, see what comes up there.

And… the problem persists even on the other MacBook (a more recent model, bought in a different shop), which is still on MacOS 10.12.6.
I created a new project, copied the text snippet a number of times up to 76K words and, bam, same problem. Getting ever so paranoid, I even created a new project and typed in a text manually, with lots of apostrophes, and duplicated it to 54K. Same problem.
Baffling…

One important thing: I only get the spinning ball as soon as I do more complicated things like using the mouse several times to select text, not when only typing a few characters. Thus, to be entirely sure that the problem occurs one best takes a look at the %CPU entry of Scrivener in Activity Monitor and see it go up to about 100%.