Page numbering is different for PDF and .docx

I’m using Scrivener 3 (just updated to latest release) on MacOS. I’ve set the page settings to have different headers and footers for first pages, and +not+ to count first pages in the page count. When I compile to PDF, it works as expected: the front matter has no page numbers and the first page of chapter 1 is numbered page 1. But if I compile to Word (.docx) with no other changes, the first page of chapter 1 is numbered page 9 (there are 8 pages in the front matter). Is there a setting I’m missing, or is this a bug? Thanks!

At this point I can work around the bug by post-processing the word doc and setting the starting page for the body of the book at 1. But then the table of contents is screwed up. No word yet from Scrivener tech support!

Given it’s their Christmas holiday, I wouldn’t expect an answer in the immediate future. See

Happy festive season! :slight_smile:

Mark

Scrivener tech support has gone home for the holidays:
https://forum.literatureandlatte.com/t/customer-support-closing-dates-for-christmas-2017/39146/1

The appropriate settings can be found in the Page Settings tab of the Compile Format editor. The settings should carry over between the PDF and DOCX output, but you can also force a given number of first pages if the automatic detection isn’t behaving correctly.

Katherine

Yes, thanks, Katherine, I did find the settings and I have them set (I think) correctly, but the fact is, when I compile to PDF the result is correct and when I compile to .docx the result is not correct. I don’t make any changes to the compile settings other than to compile to a different format. I can fix it in the .docx file by resetting the page count in the body of the book, then updating the TOC, but it’s a post-processing step I’d like to avoid, since it’s extra work and error prone. If this is intended behavior, then I guess I’ll have to work around it, but the fact that you say that the settings should carry over between PDF and DOCX suggests that this is +not+ intended behavior, but a bug.

Merry Christmas!

If you think it’s a bug, please first make sure you’ve installed Scrivener 3.0.1, which includes all known bug fixes.

If that doesn’t help, please open a support ticket, but be aware that it won’t be addressed until after our holiday shutdown.

Katherine

I think this is a bug or limitation with the DOCX convertor Scrivener uses; the DOCX contains the correct Sections (Front matter is section 1 without page numbers), but the Section after, Section 2 does not have the “Start at” set whether you enable or disable the options:
Screen Shot 2017-12-23 at 13.33.26_SML.png

I also suspect it is a bug (even with 3.0.1), and for the life of me, I cannot find a way to force the page numbering to start at a number higher than 2 when compiling to .docx or .doc.

As it does for kozmickid, all works well when compiling to PDF.

Katherine, yes, I’ve installed the latest version 3.0.1. I had the problem with 3.0 and still have the problem after the update. It’s not urgent; as I said, I can work around it by doing a little post-processing, but I definitely think it’s a bug.

Happy holidays!

Wow. You’re right. I didn’t even notice that the drop-down for the number of pages to skip is different for PDF and DOCX. That definitely looks like a bug.

Yes, this is does look to be a bug. Here is the RTF output (which is more accurate for figuring what Scrivener alone does, since .docx adds the complication of the Java-based third-party conversion engine), as examined in Nisus Writer Pro’s sidebar where a section’s page numbering is established:


[size=80]Left: result from Scrivener 2.9; Right: result from 3.0.1[/size]

Here is the section break and header reconfiguration in the 2.9 RTF:

[code]\b\fs36 \cf0 \sect\sectd

\pgnlcrm\pgrestart\pgnstarts1{\footer {\pard\qc {\f0 \fs32 {\chpgn}\b0 \i0 \ul0 \par}}}
[/code]

And in 3.0.1:

[code]{\keepn \f0\fs48 \cf2 \sect\sectd

\pgndec\pgncont{\header {}}
{\footer {\pard\qc {\f2 \fs24 {\chpgn}\b0 \i0 \ul0 \par}}}
[/code]

I’m running 3.01 and also facing this issue. Look forward to a fix in upcoming versions!

Thanks for the reports everyone. This one has been identified and fixed for 3.0.2.