Any fix for carriage return bug in section layout formatting when compiling to ePub?

Hi.

I’ve wasted several hours trying to make a section layout Suffix retain a different format to a Title when compiling a novel to ePub. I now strongly suspect it’s not my ignorance, but a bug.

I want the Suffix (<$custom:PoV>) to be italicised and sit below the document Title, which I wish to be a bordered heading. I don’t want the Suffix to appear in the auto-created ToC, just the Title.

However Scrivener refuses to retain the formatting settings and reverts to one or other defaults. The CSS includes bordered and subtitle refs.

I’m using the default ePub3 compile format, Chapter Title section layout and standard stylesheets. I don’t wish to customise at the CSS level or else I’ll be documenting software, not creatively writing!

With a bruised forehead I just dived into the big bad web and found this mentioned in Reddit: https://www.reddit.com/r/scrivener/comments/12xyn4h/formatting_keeps_resetting_in_section_layout/

So is this bug going to be fixed soon (looks like it’s been around for months), because it’s been an extremely frustrating experience. Or is there a temporary workaround I can use?

Thanks for any update or fix you can provide.


This is what I want:

This is what I get:
image

Put the placeholder in the concerned document(s) itself/themselves ; directly in the editor.
Use a style to format this element the way you want it to look.

There might be better workarounds, but that’s what comes to my mind.

Thanks for the suggestion but I’m not sure that would work in a practical way. The possibility to use ‘as is’ formatting as a section layout is available, but the section type for this issue is at the header level. This means I’d have to convert my folders (=chapters) to documents and add the ‘PoV’ placeholder in manually, as you suggest. I’d then need to adjust the compilation to add another structure type.

This adds another layer of complexity and management to the compilation - in effect, another 28 documents, one for each chapter. If there was a change required then I’d need to manually update those 28 docs (unless there’s an ‘#include’ function for a doc placeholders?).

This seems overkill to achieve what is, at heart, an aesthetic border preference in a chapter heading, which is being hindered by a programming flaw.

Thanks again, but I’m really hoping there’s a better workaround!

I really don’t see why you’d have to create any new document in the binder.
Whatever binder file or folder was routed to the section layout that won’t do what you want, you paste the placeholder in the editor and that’s it.

If the file already contained a body text you leave the section layout as it was, minus the placeholder, and if it was a folder with no text prior, you just check the text in its layout.

That isn’t it or I wouldn’t be here. This problem has been reported several times. I’m looking for a fix or a workaround. The one suggested in the Reddit post thread (add a whitespace character before the suffix) isn’t working for me.

Maybe reproduce the issue for yourself and see if what you suggest works. Remember that I’m after a Suffix to be styled as a Subtitle and its Title to be styled as a Bordered Chapter. That’s it.

Seems to me that when you place the Title AND the Subtitle in the Title Options tab, and not the Suffix tab, you should be able to format both the Title and the Subtitle in the Formatting tab, including the empty line inbetween.

CompileSectionLayoutsTitleOptions

1 Like

Yes. I used to work this way. I used to read in a <$Synopsis> placeholder (formatted as italics) in Title Options, which read in a change in date, signalling a different time period.

Later, I found a better option, because the downside of a placeholder is it creates an unwanted space in situations where there is nothing at the source to be read in, e.g. not all chapters happen on a different date. The OP wants to read in the POV, which shouldn’t create the same dilemma as there’d be a POV for each chapter.