I have seen several topics on compiling issues of late, but didn’t find one that solved my problems. One issue that may have to do with the bad Word problems I’m finding is Java: Apple and most security folks are strongly calling for not installing Java, and I have followed suit. I really don’t want to do anything about that as I would rather avoid the security holes in Java. The problems with Word conversions include the handling of Facing Pages (adding page breaks when needed, etc), and rtf output didn’t help.
Setup: Scrivener 2.4, Retina display mac 10.8.2, trying to output to a customized “paperback” format (took the template, made the page sizes and other aspects as I wanted). Outputting to word and pdf.
But some of the problems are still there even in PDF converts. The Facing Page issue is unpredictably present. Since I’m going for paperback, I have the new chapters starting on the recto side (right, odd page number) with no header (but I do want a footer but can’t get it, more on that in second). The headers and margins should alternate for “'mirroring” which seems to work.
Problems;
First chapter page footers never show. I can get the headers suppressed, and I select the “Different First Pages Header and Footer” leaving the header blank and adding <$p> to the footer. In PDF output or Word, there never is a footer page number.
Random loss of page break/recto first page of chapter formatting. Every now and then (Chapter 18, chapter 44, etc), the first page will start on the reverso (left, even page). Also, it wasn’t always this way: first compiles had no such errors. As I made changes (adding some quotes to the beginning of chapters), suddenly some (very few) chapters lost the compile setting formatting.
I can fix all this in word etc with some effort, but was wondering if there are solutions in Scrivener. Thanks.
Well, to be fair the component of Java that is under scrutiny right now is the online component, or the plug-in that sits in your browser and can be triggered by remote web sites. If you disable your Java plug-in in all browsers or anything else that connects to the Internet and uses it, then you will eliminate 99.9% of the security issues. You will only be at threat from downloaded .jar files that you run yourself, just like any other trojan (i.e. it is no more risky to download Java programs and run them, than it is to download any other form of software and run it). You may read otherwise, but these are just blanket statements because it is easier (and safer) to tell “the public” to just uninstall it, rather than explain all of the steps required to disable it. This is why Apple has taken the steps they have with their controversial security update that disables the browser plug-in component. It doesn’t uninstall or disable all Java.
In short, there is no significant risk of running Java code “offline”, as a component of Scrivener’s converters.
That all said, you really don’t need the Java converters if you own Word. Those are mainly going to be of use to people who do not own Word, but still need a genuine Word document output (and that is a fairly slim group of people; mainly those who use mobile office software that cannot parse RTF, and Apple Pages users). Most everyone else can and should use the RTF format as it is Scrivener’s native format, and so thus closer to the source. It is also going to be measurably faster compiling an RTF than .doc/x or .odt. RTF files are fully supported by Word (it is a Microsoft format after all), and in many ways are indistinguishable from .doc files in Word itself.
Hopefully all of that info helps smooth out any wrinkles in the current process you are using, one way or the other.
As to the problems:
Page numbers on chapters should be working for you. I have tested this with the Paperback preset with default settings. All I did was add [b]<$p>[/b] to the centre footer field in the First Pages tab. I did not need to touch a single checkbox. You might try temporarily saving your current compile settings to a preset (so you can get back to them), then check out the defaults again, test them to make sure they work, and the duplicate those settings in your custom setup.
It’s hard to say what the problem is since it sounds to be content related. Are the chapters with epigraphs the ones that end up on the wrong side? Is it completely random? Do the results change every time you compile? If it is a static problem for certain chapters, I would examine the draft text with [b]Format/Options/Show Invisibles[/b] enabled, to make sure there are only spaces and paragraph breaks around the chapter change point (checking both the tail of the preceding section and the text immediately following).