IF you (a) create a custom Project Format, AND (b) enter custom header/footer margins, AND (c) attempt to compile for docx, THEN (d) the custom margins will be ignored.
Instead, Scrivener will vertically-center header text in the top margin, and vertically-center footer text in the bottom margin. When you inspect the header/footer margins in Microsoft Word, you will see that the reported header/footer margins vary depending on the font size of your header/footer text.
This problem appears to be limited to compiling for docx. Setting custom header/footer margins works correctly when I switch to compiling for PDF.
STEPS TO REPRODUCE BUG
File > New Project…
Select the “Blank” template.
Save the new project.
Create a new document. Write in it, “This is a test.”
File > Compile…
At the top of the window, select “Compile for: Microsoft Word (.docx)”
In the bottom left corner of this window, click the “+” button to “Create a new compile format.”
From the list on the left, select “Page Settings.”
Now under “Headers and Footers,” click on the “Options” tab.
Unclick “Different headers and footers on first page.”
Again under “Headers and Footers,” click on the “Headers and Footers Text” tab.
Enter the word “TEST” for both the header and footer in the left, center, and right positions (six times total). Set the font for both header and footer to Helvetica. Set the font size for the header to 24pt and the font size for the footer to 12pt.
At the top of this “Page Settings” interface, unclick “Use project page settings.”
Click the “margins” button. We’re going to create an extreme example. Enter 3" for the Top and Bottom margins. For both the header and footer margins, enter 1".
Click “Save” to return to the main “Compile” interface.
At the bottom of the Compile interface, click the “Assign Section Layouts” button.
Under “Section Types,” select “Section.” Under “Choose layout for ‘Sections’ documents,” select “Text Section.” Click the “OK” button.
Back in the main Compile interface, select “Compile: Current Selection.”
Export the file as “TEST.docx”
Open TEST.docx in Microsoft Word.
Format > Document… > Margins
Observe that the margin for the Header is 1.3" and the margin for the Footer is 1.4"
Go back into Scrivener and change the font size for the header from 24pt to 12pt. Now when you export a new docx file, Microsoft Word will report that the Header and Footer margins are both be 1.4".
Next, go back into Scrivener and change the Top and Bottom margins to 2". Now when you export a new docx file, the Header and Footer margins will both be 0.9".
(Note that the “Preview” button in the “Page Settings” interface only displays Header and Footer text at the default minimum distance from the edge of the page. Clicking the “Test” button produces the same results as exporting the docx file via compiling.)
I’m using Scrivener 3.2.3 and Microsoft Word for Mac 2011 (v.14.6.1). The computer is a 2017 iMac, OS 10.12.6.
The margin settings work, but they’re for the text, not the headers and footers.
“Margins” have seven possible settings: Top, Bottom, Left, Right, Units, Header Margin, and Footer Margin.
Top, Bottom, Left, Right, and Units work correctly.
Header Margin and Footer Margin refer to how far header/footer material is from the edge of the page. For instance, I might want the margins for my text to be 1" on all sides – but I want the chapter name 0.5" down from the top of the page, and the page number 0.5" up from the bottom of the page.
It is these Header and Footer Margins that are ignored when I input custom measurements.
“ Header Margin and Footer Margin refer to how far header/footer material is from the edge of the page.”
Not in Scrivener.
You are mistaken, @drmajorbob. See Section 24.20.4 of the Mac Scrivener manual, which describes the pane @Sven appears to be using.
@Sven, are you able to define the margins as described if you create a new document directly in Word? Word may be refusing to honor those settings if it believes that you are placing text outside the printable area of the page, which would be based on your default printer.
Also, if you Compile to RTF and open the result in Word, what happens? This will show whether the issue is in Scrivener, or in the conversion to Word format.
Thank you for referring to the manual, @kewms — the panel described in 24.20.4 is indeed where the problem shows up. I don’t have privileges to share a screenshot yet, or else I would.
In Scrivener, you do not have the option to set header/footer margins for either RTF or DOC exports. The header/footer margins option is, however, available for DOCX or PDF formats. The extra settings work correctly for PDF, but not for DOCX.
The header/footer margins can be successfully changed in Word. In the steps for reproducing the bug that I described, I deliberately suggested a Top margin of 3" and a Header margin of 1" to help make it clear that this is not an issue of attempting to place text outside the printable area of the page.
Scrivener seems to be very well made software. My hunch is that I’ve found an esoteric corner of the program where the variables that a user inputs aren’t being aren’t being properly passed forward to the module that’s meant to use them. My goal here is to help out the unlucky programmer who ultimately has to hunt down the troublesome passage of code.
Header/footer text appears to be precisely centered between the edge of the paper and the edge of the Top or Bottom text margin. I believe the header/footer margin measurements that Microsoft Word reports are a calculation of that center point minus some portion of the font size plus line spacing. My lengthy bug report includes details that document how font size changes what measurements Word reports.
Unless you changed it in the past few years, it’s a fact verified in my own experiments and now, I think, reported by the OP, that the setting is as I described it and the headerrs and footers are vertically centered between the end of the page and the text. I’ll test it again when I get around to it.
The expected behavior is as described in the manual. If that’s not what is actually occurring, then there’s a bug.
Now I think the tests I did earlier were in Scrivener 2. At that time, I did exhaustive tests, and the headers were centered in the space outside the text margin settings. That said, the OP seems to be describing something similar.
I am able to reproduce the problem. I tested for the Header Margin setting (with 3" top margin and 1" Header Margin), and the header margin setting is being inappropriately ignored, just as reported.
Thank you for saying this so clearly. Yes, the behavior I reported in the original post does NOT match with what’s described in the manual.
The passage that @kewms cited (24.20.4) is exactly how I found my way to the header/footer margin settings in the first place. In “User Manual for macOS, Revision 3.2.0” the relevant text reads thus:
Header & Footer margin
Designate the distance of the header from the top of the paper, and from the bottom of the paper for the footer. This distance does not take the margins into account, and should not exceed the margin size so as to avoid running headers or footers into the body text.
To disable this feature, set the distance to “0”. The result will be to place the header or footer within the top or bottom inch (regardless of units used) of the paper.
I’ve added this to our internal bug list. Thank you for bringing it to our attention.
The cited section of the manual—24.20.4—says that the ‘Header & Footer margin’ option is for ‘Print’ compiles (which is why it works for PDF / printing).
It does not say it is for MS Word compiles (which is probably why it does not work for Word).
Is this really a bug?
The quote below, by @KB, is apposite, I think …
Header Margin and Footer Margin - allows you to determine precisely how far up or down the the header or footer is from the top or bottom of the page (for print and PDF only). Leaving this as 0 results in the default behaviour of centring them.
Nice find. Still, these extra margin settings show or don’t show depending on the output type. They show under pdf settings and not under rtf settings, for example. So, it seems clear the UI is meant to offer the option where the option is available.
So, either the extra settings should work for docx or we should not be seeing the option there. Either way, there is something to fix, I reckon.
BTW, this also shows in a small way that, the manual isn’t quite the absolute. The UI also speaks to us.
Thank you for the helpful quote, @SWM — and I appreciate your points, @gr.
I submitted a bug report because the interface for compiling DOCX files explicitly offers control of header/footer margins – but those input fields are non-functional. If input fields hadn’t been offered (as with RTF or DOC), I wouldn’t have perceived any problem.
What @Sven said. If the setting is only functional for PDF compiles, then it should only appear as an option for PDF compiles.
I am unable to explore this any further as I don’t have Word and so cannot see what others see when they compile to Word.
If the output is a fully editable.docx file, I assume refinements can be completed in Word pretty easily. Opening .docx files (from the steps listed above) in Pages works well enough, with simple steps needed to hone the headers and footers. Don’t see why Scrivener would need to handle the precise layout of the headers and footers when Word can do the heavy lifting.
Different compile settings do give different outputs when opened in Pages, so perhaps KB left the adjustments open in Scrivener so that some semblance of layout can be passed on to Word. But from the manual and Keith’s post, it seems there’s no intention for Scrivener to do anything more than it is currently doing.
As you say, will be interesting to see the final outcome of @Sven’s meticulous work.
As I don’t have Word, I can’t see what you see, but I have complete confidence in what you have observed.
In Pages there does seem to be some impact from the different options, so perhaps they serve an interim and undocumented (?) purpose. I was mainly just pointing out that the cited part of the manual does only refer to PDF / print; not to Word.