When compiling to epub (2 or 3, it does not matter which), the Chapter (bordered heading) layout now produces a second bordered area (empty of text, so just lines ) below the chapter heading. Sigh.
Scrivener doesn’t have a universal “Chapter” layout, so you’ll need to be more specific about the settings you’re using in that layout.
I was actually very specific as to what layout I was choosing.
Chapter (bordered heading). As you can plainly see if you look at the image below.
I have been using that layout for documents set as sections for the past few RC versions. The release version, however, now returns an empty bordered heading below the bordered chapter heading in a compiled ePub.
Whether you want to use the term “universal” or not, it’s the layout that comes with Scrivener, unaltered and I’ve been using it with no problem until the actual release. In fact, I used it to create an epub the same day as I purchased the updated released full version, so it was fine in the beta/RC version.
Since you are not following, I have made screenshots. The first is the layout I have been using as it comes out of the box.
The second is the resulting heading in the ePub
And the third is what I believe has caused the problem.
I have been able to get the results I want by selecting the Chapter with Title (bordered heading) layout and deselecting the title in the list of things to compile.
Editing the layout as it comes out of the box to get rid of the empty border would probably involve setting the text to custom in order to be able to change that empty space from a heading to omit the border. I have not had time to test this a bunch, but my first attempts were not successful. I set the text to custom, changed that space to body text and saved the layout with a new name. Got the same results in the compile. Did not have time to continue fooling with it, so I came here to report the problem.
To be even more specific, I can actually change that section to body text and save, but if I do so and then compile, the second border appears again, and when I open the editor pane, that section has been reset to bordered. I thought that switching to “text and notes use custom formatting” might give me the control I needed to change that setting and make it stick, that was not the case. I can edit the layout all I want and every time it closes, that empty space reverts to bordered.
It’s not a layout that comes with Scrivener, not for all projects. It’s a layout (perhaps) in the project template you used. The last user I helped had only “Heading” and “Section” section types in her project. You didn’t show the layout before, and I didn’t try to guess what’s in it.
You still didn’t show the relevant portion (I suspect) of the layout. The preview shows a blank line, but it doesn’t give us a clue why it’s there.
Show invisibles, open Title Options in the layout, and check if there’s an extra pilcrow causing the empty line. If not, check the section type for whatever document comes next.
Also check paragraph formatting for the paragraph title paragraph to see if it’s double-spaced or has After spacing.
If none of that helps, we can do a Zoom session. Message me.
It’s a layout that came with Scrivener. I used the novel template direct from Scrivener to create the project.
Before you tell me again what you think I am doing wrong, please do the following,
- Create a new project using the novel template from the fiction menu that does, indeed, come with Scrivener. Do not type anything into anything. Do not change anything so the template remains empty and pristine.
- Click File, Compile, and select ePub 3 (or 2 because it makes no difference)
- Click Assign Section Layouts and then select Scene
- In the box that opens, select Chapter (bordered heading) for the scene layout.
Compile and then look at the chapter heading
When you have done that, come back and tell me what happened with the bordered heading.
When you have done that, come back and tell me what you think I did to get the blank space.
I created an ePub, found out the new version was out, paid for the upgrade, downloaded the new version, changed a link in my backmatter and compiled using the exact same settings I’ve been using and got the double heading where it had not been before. I have now tested that it’s INHERENT to the paid version by creating a new, blank project.
Something happened to this layout between the latest RC and the release version. I came here to alert the creators that it did.
Disregard.
@drmajorbob: In fact the “Ebook” compile Format is a global format installed into the software, and like all such formats, is available to any project one creates. It has a singular behaviour that all projects share. It thus has a list of Layouts that all projects share. Whether you are being pendantic about something beyond that is probably irrelevant, as your main point seemed to be that the OP was referring to something vague, when in fact they aren’t. Post #1: ePub3 or ePub3, “Chapter (Bordered Heading)” Layout. It’s right in the very Format that was pointed out in the checklist above your post, using the Novel template (though as mentioned, one can use Blank, or Scriptwriting, or Recipe book, it doesn’t matter as “Ebook” is, like “Basic MultiMarkdown”, available to all projects).
That aside.
Thanks for the detailed report, LauraV. This is very easy to reproduce, and potentially related to a similar bug, whereby word processing files have empty lines around the heading similarly styled as the heading, causing multiple erroneous entries in the document’s structural navigation menu. In this case, the empty line following the heading is being assigned to “heading 2” with the “bordered-title” class. So it acquires the visual apparatus of the bordered title heading.
It’s unclear as to why it is even inserting an empty line below the heading in the first place, but we have enough to get it looked into at any rate.
Sorry, Ioa, I see you’re familiar with a bug that resembles this, and I apologize for coming off as contentious.
Still … if I’m debugging a Compile problem, I do not — and cannot — assume layouts didn’t change.
Case in point, I found one of my own layouts corrupted just today. The Suffix was empty (it shouldn’t have been), yet the project compiled as if the missing <$title> and <$img> tags were still there. When I put back the missing code, Compile gave me duplicate titles and images. To fix it, I had to delete that layout and create it again.
If I assumed the layout couldn’t have changed (because I didn’t change it) or even was what it plainly seemed to be, I’d never have solved the problem.
Yikes, this was happening with the Mac or Win version? And to be fair I think it is safe to not assume a custom format is immutable, for a variety of reasons—one of which is that it is loaded in a read/write state whenever you edit it. Therefore a bug in the software could cause it to become damaged. I ran into a few such issues during beta testing, where settings made on the Mac would be lost when merely opening the format on Windows. Hopefully those are all gone at this point.
It’s probably unlikely that would happen to a built-in, as I don’t think these are actually installed as files anywhere in the install folder, and besides the software doesn’t let you load them in an editable state, they must always be duplicated first (and that there is where bugs might creep in).
I found and fixed my layout problem on the Mac, but the layout could have been corrupted on Windows. No way to know.
I only go to Windows to help users and for beta testing (v3 is still a beta IMHO), and I should never use my own WIP for that, I now realize!
Yes, built-in compile formats can be copied and edited. I don’t assume a user didn’t do that … or will say if they did … or knows if they did or not. If they did, it’s vulnerable to corruption as you say.
Okay, I found where the empty line is coming from. There are kind of two problems here: one is that there is an empty paragraph at all. It looks like that is coming over from the original Mac format. If you compare the “Chapter” layout with the “Chapter with Title” layout, you’ll see there is no unnecessary empty line beneath the “subtitle” and the first paragraph of content—i.e. the empty line is where the subtitle was.
That said, and aside from best practices, the actual software bug itself is that this empty line refuses to have its style and HTML element settings disabled. You can see this by clicking into it in the Formatting tab of Section Layouts, and trying to use the Format bar to set it to “No Style” + “Body Text”. Click away to another layout and then back—and there is the bad setting again.
Thus the workaround for now is to go into the Title Options tab and remove the paragraph break that has been inserted after the prefix. My guess is that when this layout was originally made, it was duplicated from “Chapter with Title” and the checkbox simply disabled, rather than also clearing out this break.
By the way, if you do want to play with the spacing a bit, as that will bring the first paragraph closer to the heading than normal, go into the CSS compile format pane. Locate the “.bordered-title” selector at the very top of the “Custom Stylesheet” section, and add the following directly after the opening curly brace:
margin-bottom: 1.78rem;This value matches the amount of spacing added after the subtitle element when it exists, and so if you do use that variant elsewhere, the formatting should look consistent between sections.
Oh, thanks. I will try that.
Oddly enough, I used that layout in the RC versions with no problem. My workaround for it now has been to just use the one with the subtitle beneath and just untick title to make it not show.
It was when trying to change it didn’t stick that I figured there was stuff I didn’t have access to alter. 
I do think that up until the very last RC, or maybe not even in any of the RCs at all, the “Ebook” compile format was an old placeholder that had never been fully updated and fine-tuned for production. One of the main problems with it, as I recall, was that it wasn’t actually assigning the proper styles to headings, which could cause headings that looked centred coming out left aligned. It is these styles that cause the border adornments to be added around the text. So this bug in particular went unnoticed the entire time, as the conditions to arrive at it were not available.