I wonder if there could be a workaround… in the way of using a rare symbol instead of a page break as separator, then having the compiler’s replacements to replace that said rare symbol with a line break.
@MimeticMouton Is there a way to insert a page break in the replacements without compiling through MultiMarkdown ? So while compiling straight to RTF ?
No; the syntax here is all escaped, so you can’t just enter an RTF page break marker. You could use a unique symbol as a custom separator, but you’d still need to do the final replacement post compile, and at that point I figured simply using the find/replace on what’s already there (the new-page section break plus empty line) was the least work and leaves the compile format intact for when the bug is fixed in future and it works as it’s supposed to.
I’m compiling a book of poems, each of which is a text document with the body of the poem starting on line-1. The poem title is in the custom metadata field “Title”. It’s applied during compiling as a prefix.
The “New Pages” portion of the section has “0” blank lines set for the top of a new page, and the placeholder is on the first line.
There is nothing in the “Title Options” section
What might I be missing that is putting in that unwanted blank line in the compiled output?
I am having an issue when using the option for different page numbering for first pages, which inserts a section break (page break) in word. What ends up happening is that after the section break, scrivener adds an extra carriage line return, which ends up results in a blank line at the top of the next page.
Without different first page numbering:
With different page numbering:
I might be talking through my hat, but that kind of looks like the header issue I encountered a while back when syncing RTF files with LO.
That, @AmberV would know.
Yes, possibly - I’ve encountered the header issue when synching to rtf as well (to open with Word).
To me, though it looks like the issue is that the section break is inserted prior to the carriage return, rather than after. From what I can tell, this extra space appears any time Scrivener inserts a page break from the compile, though I haven’t tested it thoroughly.
I’ve resolved the issue by using Word styles that inserts a page break prior to Heading 1 + a word Macro to renumber the pages. But it would be nice to just have Scrivener to do it for me without the stray empty line.
I’ve merged a couple of separate reports for this issue into the original bug report thread. See this post above for the original response.
If someone can confirm, it would appear that new pages after a page break are now padded with an empty line even though the function is set to “0”.
In LibreOffice:
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.
