When trying to use facing page headers and footers and compiling to .docx I only get the main headers. The even (facing) pages have no header or footer. I also got NO headers or footers compiling to .pdf.
This is Version: 2.9.9.2 Beta (887615) 64-bit - 06 Apr 2020
Since no one has replied, I thought I’d mention that this is still an issue with RC5. Added screenshots of scrivener settings and the output.
This has been filed. Thanks.
Perhaps this is related: I’m not an avid user of Scrivener, but I haven’t been able to compile a paperback PDF that respects the facing page margins (all pages appear to default to the “recto” layout) in Windows 2.9.9.5. (Mac version 3 does.)
Both things - symmetrical margins and headers/footers - don’t work on .odt compile as well. This means that the problem is upstream.
As I recall, Scrivener uses “aspose” (external utility) for both these outputs, so it seems likely the issue is there. However, the problem could easily be in the way Scrivener passes parameters in that function call.
Likely the latter. But I don’t know how Aspose works, so everything could be.
Just to confirm this is still happening, I’m using 2.9.9.9 and same as GMJS reported (on 2.9.9.5) the “facing pages” compile setting doesn’t alternate margins when outputting a Paperback PDF.
This is still an issue with RC 18. Not only that, but now the text runs off the page when compiling to docx format.[attachment=0]RC18-WordsRunOffPage.PNG[/attachment]
Regarding the lack of proper facing pages treatment, as noted that is already on the priority fix list.
Precisely, and when trying to pin down the source of a problem, the right thing to do is compile to RTF which requires no conversion. That is Scrivener’s native format, and what it is providing to Aspose for conversion into other formats, like ODT and DOCX. If the problem exists in the RTF, no amount of conversion will fix it.
That to me looks more like what happens when the right indent marker is set to a position that falls outside of the paper size, and is opened in a word processor that takes that edict literally (as I think Word does). Do you get this same effect when using a compile format that cleans up editor formatting, like “Manuscript (Times)”? If not, make sure your ruler settings in the editor aren’t out of bounds. Bear in mind you need to add the left margin width the number you see on the ruler, which is 0 at the text edge, not the paper edge. But more often than not, the right answer is to remove the right indent entirely, by sliding the marker all the way to the right, unless you really need to offset from the right margin (as sometimes seen in block quotes, etc., certainly not for block body text).
I don’t get this result in RTF, when compiling default formatted text through the Times format.
Prior to this release, I’ve never had this issue of the text going off the page unless I’ve selected Preserve Formatting. What I select in the editor should have nothing to do with what I set in the compile settings.
That can often be true, but it isn’t a hard-and-fast rule. Styles, to mention one such case, have a built-in “preserve formatting” behaviour that has the strongest amount of precedence in the software, only to be overridden by a like-named style in the compile format itself.
That said, do the basic symptoms I’ve described match the output? If you check the ruler on one of these paragraphs, is the right boundary set off the page, and does dragging it back into the page restore normal text flow?
If so I’d investigate how it is getting that way through different combinations of settings, sticking with defaults as much as possible. If not then the issue is elsewhere, but the same pattern of trying to reproduce the problem at basic settings (i.e. make a new blank project, paste some plain-text lorem ipsum, compile with default settings), and building up to the error condition step by step is how I usually go about tracking down a bug.
@ lukerahl : Probably uploading a small demo project with few documents and dummy text inside is the best way to trace this further.
Looks like the new release (2.9.9.19) fixes this issue. Thanks, guys!
Great! Thanks for the update.
