Change to Version 3.1 Caused Problems

After upgrading to the latest version, I had to make a quick change and reupload an ePub. I compiled the ePub using my eBook format. Luckily, I noticed that first line indents had gone away. Had I not noticed, it would have been a disaster. Apparently, removing the choices for the two different ePub formats resulted in that.

I made changes to the indent (which were problematic because I’m still not a pro with the new compile format).

I noticed that now the font for the section titles is slightly different and the space at the top is different as you can see below.

Perhaps I did something wrong to cause this, but if not, be aware that I caused a lot of grief for me. Please handle future changes differently.

Hmm, if you had a custom format set up for ePub 2 then it should have gone on using that in 3.1. Otherwise if you are referring to things having changed between versions within the scope of ePub 3, it would be good to know what settings I should start with in 3.0.3 in order to see the issues you describe in upgrading. A sample copy of the compile Format might help, which you could dig out from a backup copy.

To do so without risk of modifying the Format, right-click on the extracted backup copy of the project and select “Show Package Contents”. Drill into the “Settings/Compile Formats” folder and copy out the desired .scrformat file. I can drop that into a test project over here and see how it goes.

Thanks. I did that, but the Compile Formats folder is empty. The highlighted format is the one I used:

I opened an older version a project and exported the format. Here’s a link to it: … ormat?dl=0

Have you gotten a chance to do that? I’m finding a number of compile-related things that have broken after my upgrade, and I’d like to understand what happened (for future reference).


Sorry about that, I didn’t notice your response a while back. Okay firstly, here is what I did to get your format working with ePub 2 / Kindle Legacy the way it used to:

  1. Using Scrivener 3.0.3, I opened the project with the custom compile format.
  2. Edited the format, and clicked the gear button at the top of the format designer sidebar.
  3. Disabled ePub 3 and KF8 support for this format.
  4. Saved and then right-clicked on the format and exported it (attached as .zip).

Now this should cause the ePub 2 and Kindle Legacy formats to appear, and all of your initial settings should be intact and unchanged. I compiled two test .epub files, one with 3.0.3 and the other with (after making the above change so that the new version uses ePub 2), and the results appear identical at the code level. You’d want to do something similar for any other formats that were designed to be used with these older formats.

⠂─────── ⟢⟡⟣ ─────── ⠂

As for what is different, here is what a heading looks like in ePub 2, using your format (note the chapter text is weird, that’s just how your settings were, I didn’t want to change anything):

<h1 style="margin: 36.0px 0.0px 36.0px 0.0px; text-align: center; text-indent: 0.0px; font-size: 369%"><a id="doc1"></a><Chapter $t></h1>

And here is ePub 3:

<h1 class="ps1" id="doc1"><Chapter $t></h1>

Obviously a bit is missing from that in terms of formatting, the rest can be found in the stylesheet file:

.ps1 { margin: 3rem 0rem 3rem 0rem; text-align: center; line-height: 1em; font-size: 4rem; font-weight: normal; }

It’s not the cleanest way to make an eBook, but it’s the least disruptive way of taking the first result and converting it to the new stylesheet based system. Ordinarily you would of course want to design CSS for the h1 element itself, or to use a semantic class name. But that quibble aside, slapping a sequentially generated class onto an element and then applying the formatting to the class instead of the element does indeed work.

There are two things you pointed out, here is what we can learn about them from the code:

  • Font weight: that appears to be the only difference to me. You got bold headings in the past because the RTF→HTML converter saw no font-weight declaration made on the text, and left that out, leaving the weight to the underlying behaviour of H1, as established by the reader (normally it will be bold). In the new conversion system, because you stipulated a normal weight heading, you can see from the CSS that is directly referred to and set. Presumably that’s what you always wanted, since you didn’t make the headings bold in your compile format originally, but if not just go in and make sure the heading is set to bold. While doing so, I’d do things the right way, myself:

[*] In the Styles pane, create a “Chapter Heading” style, and copy and paste the formatting from the “Chapter Number and Text” section layout.

  • Make sure it is set to bold explicitly, if that is what you want, and to set “Heading 1” from the Format Bar (that part doesn’t copy and paste).
  • Return to the Chapter Number and Text layout and set the title to use the style, instead of custom direct formatting.
  • Spacing is different: the macOS RTF→HTML conversion process uses fixed lengths using pixel units for distance measurements, which isn’t the best solution for this job. Using relative units of measurement is the future proof and better way of doing things. We cannot expect them to work precisely the same though. “3rem” refers to three lines of height based upon the base document font size as set by the reader. Scaling the font size will produce a design effect similar to moving a sheet of paper further or closer to your eye—everything gets larger or smaller depending on the distance, including the spacing. Hard-coding the space to a precise size on the other hand would mean the size of the text expands or shrinks within spaces that stay largely static.

But if for whatever reason you feel that it is better to emulate the old look precisely, even though it is technically an inferior solution, go right ahead:

[*] In the CSS compile format pane, you’ll note that as a result of the above checklist, we now have a “.chapter-heading” stylesheet selector (and it should be saying “font-weight:bold” now instead of normal).

  • Switch to Append Custom CSS Stylesheet setting so you can add your own styles.
  • Copy and paste the .chapter-heading line over to the editable column on the left.
  • Change the “3rem” spacing declarations to “36px” and whatever else you wish to plunder from the original hard-coded HTML styling in the very first code example, above.
  • Lastly, there is something that can be confused with spacing as well. In the ePub2 generated book’s raw HTML, you’ll note there are actually two H1 element lines. There is the one with the visible title we can see, and then an empty line below that with the same styling applied to it. I’m not precisely sure where that is coming from—it doesn’t appear to be a consequence of the settings. Whatever the case it is hardly worth emulating that, so if you want extra space between the heading and the start of the chapter, I’d suggest messing with the bottom margin in CSS.

Hopefully these tips how how you can find the technical elements driving formatting in the previous ebook and carry them forward as desired (though as noted, what is desired may not always be technically best, in the case of pixel vs relative measurement, etc.).

Thanks for that.

I think I will just modify the formating when I find problems rather than go through those steps.