Scrivener 3.3.4 is now available from our site, through automatic updates, and on the Mac App Store. This should (I hope!) fix the crashes users were seeing on Sonoma.
Many thanks to everyone who helped track down the source of the crashes!
All the best,
Keith
Thank you for all your work on the issues. Iāve installed 3.3.4 and so far, all is well. Kudos to all who participated!
ā¦and to you Keith! Great job in sleuthing out all the nasty bugs. Hit me up in PM if you need a somewhat tech-savvy Mac user to help with any future issues.
I sent you a DM about this as well and did some follow-up testing since. I can confirm a compilation bug was introduced in Build 16142 and up. Itās not surprising that no one has caught it up until now, but it seems pretty nasty.
Specifically, I think the tweaks to page layout to address crashes may have affected compilation in that some lines at the top of some pages are simply lost. From my testing and that of my beta folks, it looks like itās either one or two lines. In total my project went from 425 pages to 419. I didnāt even notice this, but my beta readers have reported back disjointed text throughout the book.
I had them provide specific places, then tracked down when my last āgoodā PDF was compiled. It was done using build 16093. Every PDF created from that point on, has been missing the same text at the same places in the page.
I saved all the various builds we used last week to track down the crash bugs, so loaded the project with each one and checked the PDFs. As mentioned above, starting with Build 16142, the content is lost.
I will try and DM you some screen shots and can resend my project to you if you guys have already deleted it. If not, you could do a compile with Build 16093 and the latest and compare the first two lines on pages 2, 5, 12, 13, 16, 17, 18, and 19. That seems to be the pattern, when the bug bites it snips off one or two lines at the top of a page.
Seems I was wrong and some others have noticed this as well. Hereās an associated thread:
Okayā¦last post before I hit the sack. As some others noted, there seems to be some kind of nexus between this bug and the widows and orphans compilation setting.
As I mentioned, when losing text after 16093 Build, my project went from 425 pages to 419. As I mentioned above, I reverted back to the 16093 Build and my project again compiled at 425 pages with all the lost text restored.
However, I just now tested with the 3.3.4 release AND with the Widows Orphans setting OFF. The project page size dropped back down to 419, but all the text was restored. So, it seems like the 16093+ builds somehow process widows and orphans in such a way that they are no longer part of the PDF.
Just guessing here, but I figured I would pass it along.
Argh, Iām kicking myself on this one.
I think I mentioned upthread how one of the fixes worked. Essentially thereās a text container (rectangle for each page handling drawing) and a text view (handles showing the container in the UI in the page view, which is also used for printing). When the view was scaled, the text view could sometimes adjust its size fractionally owing to some weird private Apple goofiness, and when this also resized the text container to those fractional values, layout corruption followed.
To fix that issue, I decoupled the text container sizing from the text view sizing to handle them manually. When widows and orphans are used, the text view/container needs resizing to reduce the amount of text on one page and push some lines to the next. Unfortunately I missed that bit of code in the update, meaning that currently the text view is getting resized for this but not the container, meaning that the container isnāt actually pushing anything down and is instead getting cut off by the shortened text view.
Thatās the technical explanation - the good news is that this is an easy fix and Iāll have a build ready later to today. Iām going to go through and double check I havenāt missed any other areas first.
Argh 2: yep, footnotes cause the same issue.
All the best,
Keith
Okay, please try this build, which should fix the issue:
All the best,
Keith
Hey Keith, thanks for the clear explanation and new build. No self-kicking allowed, you were working your butt off to get a new release candidate stable enough to ship and sometimes things happen. I didnāt even catch itā¦my beta folks did. I owe them all scotchā¦again.
Anyway, I tested it and I think the patch corrected the problem. I say think, because Iām now both paranoid and sleep deprived 
Hereās the thing. My project was 425 pages on 16093, then shrank to 419 with bug, and now with 16237, it is 423. Iām going to try going through page by page to see where the change happened unless you have any ideas.
Take careā¦rwr
Hmm, itās possible that it is down purely to some minor layout differences between the version built on Sonoma and the version built on Ventura. Over that number of pages, it is possible that this could account for the difference. Iād like to check, though.
Would it be possible to zip up and send me a copy of the project that results in this number of pages? I still have the copy you sent me last week (Iāve deleted it from our support servers but not from my hard drive just yet) but compiling that (using the āPaperback (6 x 9) + Marginsā Compile format it was set up to use) results in 486 pages on both 3.3.1 and 3.3.4. So I assume you have made some changes since sending us the project that result in a lower page count.
Thanks and all the best,
Keith
Yep, I can send you the project version from which Iām working. Can you PM me your e-mail, or should I PM you a Dropbox link from within these forums. Iāve sent you a couple of PMs, but no idea if youāve gotten them.
I did go through each page and found minor formatting differences, usually not much to change the overall page length because it kind of resets at the end of each chapter. The was one instance where the slight formatting change caused the the text to extend to a new page, just before a chapter change, which then added a blank page so the new chapter could start on the right. That accounts for the two page difference between the versions 423 vs 425.
As for the 486 pages youāre seeingā¦not sureā¦I sent the project to Alex on Oct 3, and my backup PDF from that date was 422 pages, with the page numbering visible on the book at 416, due to unnumbered pages like title and such. Are you positive about that 486 numberā¦itās a huge change.
I definitely made changes between 10/3 and today, but at this stage they are pretty minor outside of the authorās note which was a complete rewrite. Still, thatās what accounted for, on my side, the page length going from 422->425, pre orphan bug. Orphan bug put it to 419. Turning off Orphans, put it back to 425. Then with this latest build AND orphans back on, itās at 423. Like I said, I found where the two pages went do to formatting, and also found each page that didnāt match the previous āgoodā 425 version. In each case it was a matter of a few extra lines fitting on the newest build than fit before. I will be uploading to KDP to ensure the margins didnāt change appreciably to the point where itās rejected, but other than that, maybe it is just some weirdness between compiling under one version of MacOS vs another.
Regardlessā¦Iāll stop yammering on, and get you that project file as soon as I know how/where to send it.
I didnāt actually know Iād got PMs turned on! I had them disabled for ages because I had a lot of messages asking for personal help that was better either posted publicly or to our support channel, but I guess they got enabled again when we moved to the new forum. So yes, you could send me a link there and let me know so I check for it.
However, it sounds as though that is no longer necessary and that you have already found the reason for the difference, so thereās no need to send it if youāre happy itās all working as expected. (It sounds as though it is.)
And yes, Iām certain of the 486 pages when compiled on my end (478 counted), but thatās identical on the old builds too. Ah, and actually, Iāve just realised the reason: on examining the underlying XML of your 6x9 Compile format, I see that you are using Perpetua as the font. I donāt have that installed, so compilation is falling back on Helvetica through the entire book. Thatās enough to account for a significant page count difference.
Thanks and all the best,
Keith
Yepā¦I ran into that font issue myself when Sonoma decided the Perpetua font Iād been using for about ten years should look like a series of rectangles instead. That was fun to figure out.
Iāve PMed you the files including public domain license free perpetua fonts, that Sonoma seems to like. Also sent you a screen cap of the two PDFs side-by-side.
Hope this helps!
Many thanks for the files.
I thought you said that you had accounted for the two page difference, and that it was down to a formatting change? Or did you mean that it had laid out differently unexpectedly?
At any rates, I get 423 pages for the project you just PMād me (with Perpetua) on all builds: 3.3.1, 3.3.3 (16093) and the test build that should fix the widow/orphans bug I posted earlier (16237). So the results seem to be correct. But itās odd that youāre getting 425 pages on 16093 whereas Iām getting 423 there too. (I would suspect 16093 of being more likely to be wrong, though.)
As for the question about why assistive technology would pick up the missing text from 3.3.4 that you asked in the PM, I suppose that makes sense as the text was there. It was just clipped from the drawing area.
All the best,
Keith
Bothā¦in one of my PMs to you it shows how the two files format slightly differently between builds. Those slight difference, I think, account for the page length differentiation because one time it occurred at just the right time to force both a page addition, and a blank page because the next chapter needed to start on the right, hence two page difference.
If you can, take a look at the screen caps I sent via PM at let me know if you think this is anything I should worry about. I havenāt found any more missing lines of text, but at 422āish pagesā¦thatās a LOT of lines of text.
I saw the screen cap you sent, but it just showed that a line of text that was previously at the top of a page was now at the bottom of the previous page (or vice versa) - I couldnāt see any formatting differences, only this layout difference. (The new screenshot you sent shows even more text pushed down, which is odd.) But like I say, 423 pages seems to be the correct result given that this was the number of pages generated before all of the page layout bugs crept in with the Sonoma build (423 being the number of pages generated on 3.3.1 as well as on the build posted above).
You can try this out for yourself: if you download 3.3.1 from the release notes page and compile your manuscript, you should get 423 pages, the same as the latest build.
The wrong result seems to be 425 pages (itās strange you are seeing that in 16093 when for me 16093 results in 423 pages too). But the build you are seeing that in - 16093 - was part of some random tests, changing different things with page view mode to try to work out what was causing the crashes. Those test changes are almost certainly the cause of the discrepancy. One of the tests, for instance, was to disallow fractional values of the dimensions of the text area - that in itself would cause less or more text to be laid out on a page than in previous builds. (This change was abandoned because it didnāt fix anything.)
Anyway, the cause of the lines being cut off has been found and addressed in the latest build posted above - it was an obvious mistake, not updating the container sizes for widows and orphans after decoupling view and container sizing.
All the best,
Keith
Yep, I think youāre right and appreciate your taking the time to review the screen caps. The fractional values you mention could definitely account for the minor change.
Thanks again Keith!
I had posted ~10 days ago about crashing with Sonoma on 3.3.3ā¦ Are folks running Sonoma now back to reliable Scrivener with 3.3.5?
As you can see from Keithās posts above, the scrivener team has done a LOT of work to crush Sonoma-related bugs.
I believe I may have seen your prior postā¦had you downgraded back to Ventura? Just my opinion, but I think Scrivener is stable on Sonoma at this point.