As noted above, this is an issue we’re aware of. We talked about it recently internally, and it is unfortunately is a bug originating from Qt. We decided to put it off as we’re going to be upgrading Qt soon, and it makes sense to wait and see if it goes away, before putting effort into a workaround (which looked difficult to do).
This would be my preferred approach in general.
Ok. Thanks AmberV.
Given the fact that I was previously involved in this here thread to which you just merged mine, perhaps I should take an appointment with my doctor, have my brains checked.
Noob question, perhaps something I’m missing, but I’m finding that after selecting a Page Break as my between-sections separator, Scrivener is adding an Empty Line at the start of the new page with every Page Break.
Any way for me to get just the Page Break?
Known bug.
I think that for the moment, you have to resort to removing the extra empty lines at the top of the first page of sections/chapter manually afterwards in, say LibreOffice.
Ah I see! I look forward to its eventual squashing. In the meantime, Scrivener’s scriptwriting is way speedier than if I were to do it from scratch in LibreOffice Writer. (My non-creative-writing word processor of choice, actually!)
Here is the latest update on the status, and along with what I consider to be the best workaround (one that is so good it is what I would do if I were a word processor user even if this bug didn’t exist). Here is a more detailed description of the process, and although it focuses more on recto/verso layout the basic concept is the same, in particular how creating a setup as a template and then importing the compiled draft .odt into the template can make all of this pretty painless.
Question:
The method you linked to seems indeed very convenient, but how to have the title of a document end up with a style of its own once in LibreOfficeWriter, when it (the title) is inserted by the compile format ?
I tried applying a style to it like this :
I get this :
. . . . .
To make the question even more complex, would there be a way to have the title have its own style, while retaining the ability to have styles assigned in the editor NOT include style information in the exported file, so that they end up with a general style, and that general options can still be applied to them in a third party editor.
. . . . . . .
[EDIT] I have no explanation for it atm, but after trying to compile a document with text of that style to see if it was only the title (which had its style assigned in the compile format) that ended up with no style in LO, it now works.
I’m not sure what was going on with your first test either. The method you describe is how you would apply styles to the output in general: select the sample heading in the Formatting tab, and add the desired heading level style to it. I believe all of our stock compile Formats have matching heading styles set up, so that all one one would need to do is go through and apply them.
I would only add that for best results, to get a proper document outline in the layout tool, you would want to stick with the “Heading 1”, “Heading 2”, “Heading 3…” convention. That will give you a properly indented ToC and is otherwise how a word processing file should be set up.
And that is why the stock formats don’t do that for you because the formats are designed to address a variety of document structures. Layouts for parts would be “Heading 1” and chapters “Heading 2”, in one document, but in another without parts, where chapters are the highest organisational unit, they would be “Heading 1”. The “Titled Section” layout may go from “Heading 3” in one book to “Heading 1” in an article or essay.
Thanks AmberV.
So I guess that the answer to my second question is that it can’t really be done then. (?)
. . . . . . .
Yep. I agree 100%. (I just went with whatever style was already in my testing compile format. – It is a case of “Don’t do as I do, kids”.)
[EDIT] I went back and updated my screenshots so that I don’t give anyone bad ideas. 
I don’t know if I entirely understand the question, or if I do, how it relates to any of the above. If you’re asking about how to effectively work with internal-only styles that are used purely for the writing process, that’s an interesting topic but one for another thread as that won’t help anyone getting notifications for this bug report, unless I’m missing something.
Yep. I think this is what I did.
I mean, I want them (my styles) to be usable to format/reformat text segments through the compile format, I just want to be able to have only my title that was inserted through compile to have a specific style once in LO.
So that, for example, I can set LO not to split paragraphs for all the styles at once (like I can currently do, say I don’t care about the extra line the page break adds, since all my styles end up as a single “Default Paragraph Style”, like in my previous screenshot).
To reformulate the same question a different way:
Is it possible to have my title end up styled in a third party editor without using this setting:
Feel free to split to a new thread if you see fit.
I certainly don’t mind.
This issue has been bugging me for months. Glad to see there are eyes on the problem.
@AmberV
I was able to partially answer my question on my own, by overriding my styles’ name to a single identical name…
That could somewhat be functional (although it is getting close to as much trouble as to fixing the bug manually, at this point) but it leaves “no style” as a third style once in LO…
(I personally just reached the point where I’m thinking “Meh. Screw it. I’ll deal with it by hand, hopefully the bug will be fixed soon enough.”)
Still, I have to say that should I not be using so much styles in the early phases of composition, the solution you pointed to would be ideal.
(At the early stage of my composition process, I kind of only compile so that I can further work a chapter/document in a printout form. My current solution is to compile and print a single document at a time. I am ok with that. Else, the bug ain’t a real problem in that context. I can totally live with the unwanted extra line. It’ll only cost me a few extra blank sheets a year. (Perhaps none, even, since when I get a paragraph alone on the last page, I usually play with the header and footer size to fit it on the previous page.) Nothing to sob over. – Once I am done with the composition process, my project is down to only two or three styles, so then again, not a problem.)
I have reproduced and analyzed the problem with the supposed “page breaks” during compilation several times.
In fact Scrivener does not insert page breaks when compiling to Word (docx) as claimed everywhere in Scrivener’s user interface and documentation. There is also no extra paragraph.
Scrivener inserts a section break (not a page break!) at the end of the paragraph between the text and the paragraph marker. The section break forces a new page. This moves the paragraph marker itself to the new page, creating a blank paragraph and (normally) preserving the paragraph’s formatting attributes from the previous section. A section break, unlike a page break, means that various properties (such as header, footer, column count) are (or can be) reset for subsequent pages.
Scrivener’s procedure is equivalent to manually inserting a section break at the end of a paragraph in Word by a user. With manual insertion, the user must then either edit and reformat or delete this “new” paragraph. Unfortunately, inserting a page break at the end of the paragraph would not change the problem either, because exactly the same thing happens (a “new” paragraph is created by separating the paragraph with a section or a page break).
It remains irrelevant at which point of a paragraph a section break or a page break is inserted. The paragraph is always separated, even if it is only the paragraph marker that is moved to the new page/section. Remedy could be possible at compile only if first the page break or section break is inserted at the end of the paragraph and then the paragraph marker is deleted. But presumably this deletion of the paragraph marker will not be possible?
Thanks for the detailed explanation (sorry, my second comment overlapped with your explanation). To sum up for me, Scrivener offers many possibilities for “formatting” (like section breaks or headers/footers) - but that they really should not be used at all. Which raises the question for me, why Scrivener offers possibilities that only lead to errors (or let’s say “weaknesses”) which one should avoid with procedures with further software.
For me, I’ll continue to work on the current book with Scrivener’s weaknesses for now and just ignore extra blank paragraphs in between. At the end I will then look at whether it is worth applying a template in Word or whether I am then not faster overall with a one-time manual overhaul.
In fact Scrivener does not insert page breaks when compiling to Word (docx) as claimed everywhere in Scrivener’s user interface and documentation. There is also no extra paragraph.
That is correct, the technical formatting command that it inserts under most circumstances is a Section Break, not a pure/simple Page Break. I use the latter in common discussions to describe both, because on the surface they achieve very similar effects and that is how the software describes them.
It is possible to have Scrivener generate simple page breaks, but you would need to disable all features that require mid-document data changes like header/footer setups, front matter using different page numbering, and so on.
Scrivener’s procedure is equivalent to manually inserting a section break at the end of a paragraph in Word by a user.
So the problem that we have is that the toolkit itself handles things that way, given how it organises data in memory and then generates output from that structure. We would have to override how it handles text data at a fairly deep level to fix this. But yes, the details aside, the end result is as you describe: a user inserting a break incorrectly and then not fixing it.
To sum up for me, Scrivener offers many possibilities for “formatting” (like section breaks or headers/footers) - but that they really should not be used at all…
100%! If I were a word processor user I would use one of these two routes:
I would stick with how I write currently, with Markdown in Scrivener, and use Pandoc to generate the DOCX/ODT file—which is enormously cleaner and better conforming to best practices and conventional behaviours (MultiMarkdown’s ODT isn’t bad either). That workflow is almost exactly like what I describe doing manually in the other thread: you design a document template and then Pandoc handles the creation of the raw styled formatting and injects it into the template for you, skipping the step of importing the text yourself.
So it’s a very clean, efficient and quite powerful workflow if you need a good word processing document. I do have some quibbles with how it works—and in some areas it feels like a WIP. For example I’d rather see proper image floats with dedicated captions rather than a “Caption” paragraph underneath an inline image, but one big advantage to using Markdown to write is that our documents get better as the years go by. Stuff that I wrote back in 2008, when Markdown was in its infancy with regards to complex documentation creation, creates much better documents now, without me having to change anything about the source.
The emphasis here is that Scrivener can produce well-formed documents right now, out of the box—and writing with Markdown is probably a whole lot less about writing with Markdown than you think it might be, considering how the compiler has an RTF to Markdown conversion engine built-in. Many wouldn’t even need to see much, if any, syntax in the editor. The user manual PDF for instance, which does a lot more formatting than native Scrivener can even dream of doing, is a Markdown project—but in most sections of the source project you probably wouldn’t even notice or realise that.
If I were to abandon Markdown for some unholy reason, and use rich text formatting as a basis for how I write in Scrivener, then I would do what you are saying. In fact when I started playing with this and creating a proof-of-concept some months ago, I created a compile format that very deliberately avoids as much of Scrivener’s formatting as possible. You can’t avoid all of it, but I got it down to the point where everything about the look and feel of the document could be overridden by the template I inject the compiled .odt file into. So that absolutely is the route I would take if I had to work this way. For me, what comes out of the compiler would look almost nothing like the final product, and would be intended more as raw data.
I wouldn’t though, because even that workflow has limitations that I do not have with Markdown, such as being unable to cross-reference to figures properly (with Scrivener the best you can do essentially boils down to using markup in the editor anyway, so… might as well just use a mature and broadly supported markup rather than something that only works in one tool and produces static text instead of field references and dynamic numbering).
…Which raises the question for me, why Scrivener offers possibilities that only lead to errors (or let’s say “weaknesses”) which one should avoid with procedures with further software.
It’s a good question. Why is it this way? Mainly because it has grown organically and gradually over the course of nearly 17 years now, most of which during that time it had no proper stylesheet support at all (true, the Windows version is younger than that, but it’s core design comes from that legacy). These kinds of brute force tactics I describe above are the only way to do most of these things if the output is oblivious to styles. While styles were finally implemented, they were really only implemented at a shallow level. They are applied to text, but not even by default in Section Layouts (owing to other design corners and Catch-22s). It was, you might say, a “phase one” implementation of stylesheet support.
It’s also worth bearing in mind that for many years this was all good enough, too. Most people were handing off a Courier or TNR manuscript and it’s okay for such documents to be technically sloppy. Publishing houses have piles of macros to fix author sloppiness because authors often have no clue how to use a word processor beyond typing—hitting tab to make indents, etc. But as more people are now doing their own design, or handing their work over to freelancers that may not have decades of helpful macros in their tool-chest, the importance of having a well-formed output is more relevant today than it was when Scrivener started out.
So yeah, if one is doing things the right way and wants a best-practices document, either of the methods I described above, are the best ways to use Scrivener, hands down. If you’re not doing thorough design or embarking on a collaborative or institutional workflow that requires well-formed documents, and are just hoping for the best (maybe even using PDF then)… then whatever. “WYSIWYG” works even if what you see is “wrong” from a best-practices standpoint. 
It works if all you are doing is opening the output in a word processor and using its better layout engine to create a superior PDF than what Scrivener can create natively.
These factors are probably why this is not more of an issue. Most of the people that would even notice Scrivener’s output are, like I say, in a workflow designed to strip out sloppiness anyway.
This does not mean we shouldn’t improve, but that is deep level overhaul territory for some point in the future.
Thank you very much for your detailed explanation. I now better understand how and why one should work with Scrivener when wanting to have control of most of the process. For me I produce a document that goes straight to the publisher who does all the layout and formatting. The compiled output of Scrivener mainly serves two purposes for me:
It is the overall written product (text, no pics, no tocs, no footnotes etc.) where I can scan through it and get an impression how the whole thing would “somehow” look.
After all writing and editing it’s the interface I hand over to the publisher.
After that the rest of editing with corrections (grammar, stylish etc.) will be done in a document I get from the publisher.
So for summing up: I will work with the output Scrivener compiles. At the end I will overhaul that output, only changing as little as possible (like the empty paragraphs) and send it to publisher. For me Scrivener is a very good research and writing tool. With now knowing more detailed about the Scrivener workflow and techniques I accept that little flaw. Because no workflow is perfect but needs to be as good as necessary. For my workflow it’s the optimal tool.
Perfect, then in that case you may not even need to clean the empty lines as they’ll probably do that for you. But if you wish to, that’s another thing!
So, after spending hours poring over the Scrivener docs, assuming that I was misunderstanding how the compile settings worked, I finally looked through the forums here and discovered that this whole inserting-blank-line-after-page-break problem is actually a bug. Given that it’s a well-known bug of apparently long standing, and not addressed recently, it would be REALLY REALLY nice to have some kind of note in the documentation about the problem. Seriously. It would be a much better user experience.
Here is a method to create a Word Macro that deletes the paragraph mark above a specific style in Word. I create a style in Scrivener called Chapter Title and assign it in the compile settings to the section title before compiling. Then I add the VBA macro below to my Word document and run it and voila! All the blank lines above my chapter titles are gone.
Below is a VBA macro that you can use in Word to find every instance of a specific style and delete the paragraph (line) just before it. Please replace "YourStyleName" with the actual name of the style you’re targeting:
vbCopy code
Sub DeleteParagraphBeforeStyledText()
Dim oPara As Paragraph
Dim sStyle As String
' Set the style name you're looking for
sStyle = "YourStyleName"
' Loop through all paragraphs in the document
For Each oPara In ActiveDocument.Paragraphs
' Check if the paragraph style matches the specified style
If oPara.Style = sStyle Then
' Check if there is a previous paragraph
If Not oPara.Previous Is Nothing Then
' Delete the entire previous paragraph
oPara.Previous.Range.Delete
End If
End If
Next oPara
End Sub
Here’s how you can add and run this macro in Word:
Alt + F11 to open the VBA editor.Insert > Module to create a new module."YourStyleName" with the name of the style you want to target. Make sure the name matches exactly, including capitalization.Alt + F8, selecting DeleteParagraphBeforeStyledText from the list, and clicking Run.Note that this will delete the paragraph before every instance of the specified style throughout the entire document.