Thanks, Scrivener-folk for giving us the chance to test-drive the software before buying.
First, the good stuff - Scrivener is fun to use, great for fostering the sort of playful spirit that lends itself to creativity. Hooray!
For me, the bad news and the deal-breaker - Scrivener does not display page numbers during composition (as opposed to compile). Because I use page numbers to monitor pacing and chapter length, I have decided to return to my old (boring) word processor.
In the forums, someone suggested that I could use the word count at the bottom, dividing word count by average number of words per page. It’s a nice idea, but in practice, having to make a bunch of calculations would take me out of writing mode.
So, my wish: a version of Scrivener with a page number tally next to the word count.
Given that Scrivener is not a standard word processor that presents your document as a document, but rather as dozens, hundreds or maybe even thousands of individual sections, calculating the actual page number for an arbitrary piece of text in the middle of such a tree of information would not be possible. This is further complicated by the fact that the compile process, which glues all of these individual sections of text together into a more familiar “document”, can also omit or add sections from the outline based on their status, structural components can be grafted into the output such as chapter titles and page breaks, and indeed even the formatting of the body text itself can change when compiling. In short, what you see in the editor in Scrivener is not at all like what you see in a word processor. The editor interface and the binder outline is a text editor in the purest sense, and composition platform, not a document production utility.
Of course, calculating the actual page count is important, and so we do have tools for that in the Project statistics. This actually compiles your project in the background so that the result is accurate, and not just based upon the quantity of text you can see in your editor at its current appearance settings. In time we will be building a “page view”, which it is important to stress will not be a layout tool like in a word processor, but an aesthetic option that will be drawn in simulation of your actual compile or print settings. To me it sounds like that is more what you are looking for, than knowing that you are actually on page 276. It’s still a little abstract, but for “feeling the pages go by”, it does that.
On the other hand the human mind is nothing if not exceptional at adapting new systems of measurement innately. You may find it is possible to get used to watching the scrollbar diminish in size as a determination for roughly how long the section is you are typing in. I got used to that mechanism years ago, as I never did like writing in a WYSIWYG environment and would use plain old text editors like Notepad. To each their own, though.
Except, of course, that the Project Statistics estimate is not really accurate. According to the Pages (printed) estimate for one of my projects, I should have 58 pages after compilation, but when I compile, I only have 44 pages. That’s a discrepancy of almost 25%, which is pretty bad, in my book.
That will depend on what type of output you use and what you open the file in, this is true. There are no absolute certainties until the type is set, the best we can do is provide what would happen if you printed straight out of Scrivener. If you are finding that there is a large discrepancy between the Project Statistics printed value, and what you get when selecting the print option in compile, let us know where you feel the fault sits.
Since I only ever send my work to people digitally, I’ve never needed to compile directly to print from Scrivener before. So, I tried using the “Compile for: Print” setting, and sure enough, the number of pages for my project that I mentioned earlier came much closer to the estimate provided in Project Statistics for Pages (printed). It was still not 100% accurate, but two pages difference is better than fourteen.
My question, then, is why is the print compile different from the .docx compile (which I use exclusively)? The .docx file contains one more line per page than the compiled print version, and some of the lines in the .docx file have more words in them, as though Scrivener didn’t feel like squishing as many words into each line for the printed version compared to the digital file. Is there a rhyme or reason as to why one format of compiling alters how the words are put on the page? Because if all of the other settings remain the same, shouldn’t the two outputs be nearly identical?
I suppose what I’d like to ask for then, since this is the Wish List forum, is a Project Statistics estimate for Pages (printed) based on whichever compile setting might currently be selected, and not only be based on a single setting. As it is right now, it seems as though there is no way of verifying the accuracy of the estimate without printing out the entire manuscript, which for many of us can be rather daunting just to make sure page numbers are correct.
In theory, in an ideal universe, all formats would format equally and wherever a document was opened, it would be opened with precisely the same metrics as on every other computer in the world. Unfortunately there are very few formats that allow for that kind of consistency, and they are all static formats like PDF. The more mutable formats like Word document files, and RTF files, are all dynamic in that the program opening them must interpret the codes individually, and since every program does this slightly differently, consistency is well nigh impossible. The best we can do is provide an estimate based off of our own engine for producing printer data. We have no knowledge of how Microsoft Word opens a .docx file and parses it, and thus cannot provide an accurate preview for how Word would open that file. Furthermore many of the formats we provide have no such concept as pages. E-books, HTML files and so on have no concept of pagination. If your compile settings were set to one of those, what then would Project Statistics display?
Knowing how many words you have written is typically more important than pages. We can come much closer to an accurate count of words, than pages and that is typically what publishers are looking for. But if you must know a page count, then I would recommend not printing, but exporting to Word and getting the page count from there. There is no reason to print, because the Project Statistics panel already gives you that number. You already have that number at your disposal. It is the count in Word that matters as it is different and cannot be calculated from Scrivener.