<b25> Folders set to section type Chapter no longer show up correctly in compiled DOCX

This is an older document that compiled fine in beta 24.

In b25, only a blank line appears where earlier versions gave me “Chapter 1”, “Chapter 2”, etc

What are Chapters set to in Assign Section Layouts in Compile? What type of section are chapters set to?

(Note that this is the same compile format I’ve been using for months now)

The folders are assigned Section Type : “Chapter”.

In the compiler, the Section Type “Chapter” is assigned a Section Layout that is:
Title Options, Title Prefix defined as “Chapter <$n>”

Also, Separators -> Section Layouts : “Chapter” -> Separator Before Sections=Page Break

Previously this resulted in each new chapter starting with a page break followed by the words “Chapter 1”, and so on.

No one else is seeing this?

I get this issue even if I switch to one of the built-in formats that come with Scrivener. For example Paperback (6" x 9")

Scrivener seems to recognize my Section Types correctly like it always did in the past. But the page breaks and the chapter headings no longer show up in beta 25.

The same thing happens if I compile to PDF.

Yes, the latest bea Scrivener is completely failing for me on this issue as well. All the TOC chapter One, chapter Two, etc links from the auto-generated table of contents used to work, but now with this version I have a blank Table of Contents instead. Total failure of the Scrivener program. It’s now useless to compile an ePub or DOCX or anything.

I sure hope they address this major issue before they go live with it in a few weeks or I will be all over the forum posting buyer beware as this software still has a tremendous number of flaws.

Instead of making threats, let’s work with the L&L team to make certain it’s ready to go.

Reproduced this.

Then…
I noticed that Chapter Heading is assigned to Chapter Number by default, and Chapter Number does not have anything checked, by default.

This is in the Section Layouts tab (just above the Separators tab). If I check the Title checkbox there (the layout I’m using), it outputs the Chapter number followed by the folder’s title. It should show you the expected output in the preview pane below. If I do NOT check the Title checkbox, it does not put anything. That Title Checkbox MUST be checked for anything to output for Chapter Number (actually, I’m guessing that something must be checked in that line for anything to output at all, but we’re dealing here with titles, and Metadata is likely not wanted, nor anything else on the line).

So checking the Title Checkbox causes some issues, too; it does not automatically space. You have to put those in.

So if the Title Prefix is Chapter <$p>, I’m going to end up with Chapter 1Foldertitle.
If I put a space after <$p>, I get Chapter 1 Foldertitle.
If I add a carriage return instead, Scriv will give me

Chapter 1 Foldertitle

If my Folder Names are BLANK, I get Chapter numbers alone. IF the Title checkbox is checked.

If I named my chapters Chapter 1, Chapter 2, etc., and had no prefix for Titles, they’d output like that.

This is in PDF. I did not test other output formats, which may behave differently. I would like an option to output just the chapter numbers without their titles, but that’s not present as near as I can tell.

Does that help?

There is a bug here, however. This is NOT misunderstanding the compiling rules and settings. Yes, workarounds as mentioned above can solve this problem (and there are other ways too), but the fact is, the preview under Chapter number with NO checkboxes checked shows a Chapter number when you’re using a prefix of “Chapter <$p>”. This is what should be output, and it’s not doing that.

Here’s a screenshot:

But that’s not the output in the PDF.

Thanks, it does help as a workaround, even if I find the whole thing quite inconvenient.
Hopefully, it’s an error and will be fixed soon, but it’s still present in beta 26.

Perhaps someone from L&L can comment on whether it’s a bug or a feature?

Hi adrm,

Sorry for the delay. This issue should be solved in the most recent beta. Are you still experiencing this?

Thanks!

Hi Bryan.

It’s back to working as expected in beta 30.