UPPERCASE and centred output, what did I mess up?

I just cleanup up my format, and suddenly the first paragraph in each document is uppercase and centred.

I’m compiling for ePub3 with a slightly changed “Ebook” format.

When looking at the generated html+css, I see:

/* Direct formatting styles */
.ps1 {font-family: 'Cambria'; font-size: 1.33rem; margin-bottom: 1.33rem; margin-left: 0rem; text-align: center; text-indent: 0rem; text-transform: uppercase}
.ps2 {margin-left: 0rem; text-indent: 1.50rem}

Which explains the how, but not why each first paragraph of each document get that formatting.

I suspect I messed something up when going through the format to remove old experiments and temporary settings for proofreading, but I have no idea what causes this. It is not the “uppercase first X words”, as that uses a different mechanic and is still there in addition to this. I have no idea which setting could even cause this, so…help?

Edit: I just noticed that this does not happen in chapters where the first line of text is italic (using the default paragraph style). The blank line between the title and the text still is “ps”, but the first line itself is “ps2”. Even more puzzling…

Edit 2: This is getting more mysterious from moment to moment. I disabled “Create styles for paragraphs using custom formatting” and now it is mostly gone. The only place this style still comes up is for chapters that use a format with a title but have no title set:

But that also is weird, that should be “subtitle” like this:

Ok, it is invisible, so I could live with it, but keeping that setting off is a bad idea as the epub is now bloated with like this:

(Really? Why are all empty lines font-family:'Cambria'; anyway?)

This is too complex to solve with the information you provide.

In any case, only the last rule for paragraphs will be effective. It will overrule the onces above it.

Better clean up the CSS, and remove all Style=“” statements into the CSS…

That may be a clue. In the Section Layouts compile format option tab, click the ••• button in the top right, and check to see if Include placeholder titles for untitled items is checked, at the top.

I do agree the weirdly styled paragraph instead of getting a proper heading is odd, I don’t get that result myself when testing with the stock Ebook format, and its “Section with Sub-Heading” layout, but your setup is obviously customised.

Ok, it is invisible, so I could live with it, but keeping that setting off is a bad idea as the epub is now bloated with like this

That setting is buggy, I don’t recommend using it for any purpose as it has no actual cosmetic effect. Its sole effect is to make the ePub way bigger than it needs to be. Honestly it’s buggy with it off, too. You aren’t supposed to be getting any automatically generated paragraph classes like that unless the paragraph has raw formatting that goes against the defaults. With it off, it’s supposed to be much more blind to that and largely produce simple <p>...</p> HTML.

1 Like

Interesting. Turning this on seems to fix the issue (I do not think I turned that off?):


image

No more weird ps1 style and the first paragraphs of documents doesn’t have another style than the rest anymore.

But, in my mind, it makes no sense that that setting has any effect on sections that do have a title. It makes no sense it causes the first text paragraph to have a different style than the rest, even if can explain that style being weird.

Also, I still have these:

image

but:

image

The “weird ps1” could have been trying to implement that? On the other hand, I also see a css rule for that, but it is completely broken:

image

The top rule is mine, but the next two are those I showed in the first screenshot. The last one, the “h3 +p” that should take that indent away, is on line 3. So it is overruled by both order and specificity.

Should I send in an export of my format?

BTW: At this point, I have to call the CSS Scrivener generates completely broken, not just for this but for many more issues (like the font size I have to override with !important). I can (and plan to) replace the CSS once the book is completely final and the generated html doesn’t change anymore, that’s just a couple of hours work. But for that, the generated html has to make sense—and not randomly change for no determinable reason. Nonetheless, there are other people out there who do not have the skills to do so, and epub3 is an important format for everyone who’s self-publishing.

1 Like

Turning this on seems to fix the issue (I do not think I turned that off?

It is off by default, and ordinarily you wouldn’t want it on, so I’m not sure if that is much of a solution—but if you can make it work with it on, that’s fine (it shouldn’t do anything for Section Layouts that do not generate a Title).

I was mainly curious if had been turned on at some point, as the result you were posting looked a bit like it had been.

Should I send in an export of my format?

That could help, along with a minimal project structure that replicates the problems it reveals. Basically enough Draft structure to trigger the section layouts needed. The Format can be saved into this sample project so that it in theory works with a simple click of the compile button.

I would go about doing so by using Save As to create a demo copy of the project, strip everything out, empty the trash, and leave some lorem ipsum text behind in the necessary binder structure.

I’ll see if I can figure out what is going on and offer you a better workaround—and get anything else written up as bugs, if need be.

At this point, I have to call the CSS Scrivener generates completely broken, not just for this but for many more issues (like the font size I have to override with !important).

Oh yes, and the HTML output is broken as well, as you note. Basically, ePub output was never finished. It appears to have been programmed to work against the stock Ebook compile format’s default settings, instead. The more you push your settings away from that default, the more issues you will likely run into. Thus for those that don’t do much or any design, it “works” in a broken-watch-twice-a-day sort of fashion—so for most people using this, it’s “fine”. But anyone that does their own design, or wants to use the compiler the way it was designed to be used, will often run into issues.

I’ve said it before in other threads, but I would never mess with this exporter myself. I would install Pandoc, to activate Scrivener’s integration with it (after a restart), which will add a Pandoc → ePub entry at the bottom of the Compile For list, where you would select ePub3.

This approach can be used with a project that hasn’t been written with Markdown in mind, thanks to the setting to convert rich text to Markdown in the general options compile tab. One may need to tweak some styles so that they generate Markdown, as by default it will ignore most rich text directives.

It requires one to design the CSS themselves, though one can use Scrivener’s GUI generator to get the basics done, with some adjustments to its much cleaner HTML output. For someone that knows what they are doing though, that’s probably unnecessary.

What I do is first compile with no CSS settings, which causes Pandoc to insert a bunch of example CSS. This is a good starting point (it isn’t too opinionated) for making a design, which I do in Sigil. Once I’ve done that, I copy and paste the entire stylesheet.css contents into the “Pandoc Options” compile format pane.

It’s maybe a bit late to consider a change that radical for this project, but maybe worth looking into, and seeing if it will work for you, with the next book.

I’m biased because I vastly prefer writing in Markdown to begin with, and that is the only way I write in Scrivener, but to my mind it is easier to work toward something fully functional, and learn how that system works, than spend time trying to figure out why options that say they do “X” do not, and so forth.

Will do. I just tested it with importing the format into an empty new project, but I only could get the “the empty <p> that’s generated where the subtitle one should go is funky” to reproduce, not the “first <p> of each doc is funky”. So this means I’ll have to spend some time cleaning up a copy of my main doc.

I don’t even see how it the unedited default format can “work” for anyone. Look at this:

image

Ignore the font changing letter shapes in italic, that’s not on Scrivener. But have a look at the font size. This is the default, unchanged “ebook” format, with a new project. The original text in the editor is half in “No style” and half in the default unchanged “Emphasis” style.

Inspecting this reveals that “No style” text is in 0.92rem. Font in any character style is in 1rem, even (or especially? Never tested that.) if “include font size” is not set. So, unless you don’t use any style, not even italic, your output will be broken.


The section layout setting another font size than what is on body is an issue. The section layout styles being added at the very end, i.e. after the user css, is an issue. The character styles setting a font size is an issue. All sizes being in rem instead of em, instead of only those were it is needed or makes sense, is an issue. The section layout setting a text-indent is an issue (although this does nothing, as even the base p rule overrides it).


BTW: You may think I heavily customised my format, but I would call it “lightly”. I added a bunch of paragraph styles with custom css class names I added custom css for, but that’s pretty much a “nothing” operation as far as the format is concerned. I disabled indent deletion for a couple of cases (mainly after an empty line as I have those in my main text in places where they are not section separators). I duplicated the chapter format to have a second counter for my “intermission” chapter, and I added a header line to the section format (found that easier than using the separator feature when using chapter documents with text instead of heading folders). Other than that, I’m pretty ok with the default format in terms of how it looks. I may have toggled a bunch of settings while trying to work around weird bugs, ok.

image
(For Scrivener, that’s just two paragraphs with a custom CSS class name and having indent deletion after empty lines disabled.)

I’ll respond to the rest, but here are some instructions for scrambling content, if you need them. Otherwise feel free to drop it to me in a private message, or send it to tech support, with this thread URL for reference. Someone will ping me.

To preface, I didn’t mean to imply that there are no bugs if you use stock Ebook (!!), and even very simply at that—just that it gets worse the more you try to use the compiler as designed.

Ignore the font changing letter shapes in italic, that’s not on Scrivener. But have a look at the font size.

Setting aside the bad assumptions about character styles having a hard-coded size, the actual problem, as you note, is that all body text is incorrectly set to 0.92rem, and that is caused by…

The section layout styles being added at the very end, i.e. after the user css, is an issue.

Yeah, there is already a thread on that. It shouldn’t be generating anything at all in fact. Those divs are meant to be for your use alone, under the current design. The fact that it inserts this auto-generated stuff, forced to the very end of the CSS file is almost comedic, given that. A tool meant for users to make better books ends up being something forcing users into !important hacks to get anything done.

But even worse, the Section Layout DIV generation is broken too, which can cause formatting from higher levels of the hierarchy to bleed into lower levels as the divs are never generated for lower levels and higher level divs incorrectly wrap around entire child groups. The thread I linked to above shows you how these div classes are supposed to work.

Specifically to the font size problem you noted, it’s not that Emphasis is misguidedly set to 1.0, it’s that the div.chapter-heading section layout is incorrectly wrapped around the entire document, and has itself generated font-size: 0.92rem.

The section layout setting a text-indent is an issue (although this does nothing, as even the base p rule overrides it).

If I understand correctly, that is a noted bug; workaround given in the thread, though I suspect you know how to solve it.

Sorry, I’m a bit busy with real life atm.

I don’t need to scramble, the book isn’t exactly secret (the first chapters went up on inkitt yesterday), but I want to strip it down so you don’t have to wrangle a 150k-words file (and don’t have to look at the NSFW parts if you don’t want to).

Thx for the link to that other thread. I also opened one a couple weeks back for this but it got no replies.

BTW: I do think it is correct that a folder’s div wraps the divs of the documents inside the folder. It may make sense to add another div around the body text of a section; a fixed name would word fine as it would be inside the section div, i.e. easily addressable that way. Then “.chapter .text” and “.chapter .section .text” as well as stuff like “.chapter .subtitle” and “.chapter .section .text p” would be very nice and logical selectors. In my experience, having additional wrapper divs only makes it easier to style stuff and rarely presents an issue.

1 Like

Sure, I don’t actually have a problem with the concept of layering container divs, as you say that can be quite useful for writing efficient CSS. But by design it is meant to only wrap the content using the section layout. If you did want to implement you own full container, the idea is to leave the class field empty and insert the HTML yourself into the Prefix and Suffix tabs (ticking the option in the Suffix tab to insert it after all child items).

The problem there is that styles don’t work in the Suffix and Prefix tabs yet, which means you can’t use the “Raw HTML Block” style, meant for passing code through to the output.

But, it’s worth noting you can ultimately suppress the section layout CSS output by deleting the CSS class name from the Settings tab; forgot about that workaround.

The Pandoc output does in fact layer containers, although it uses <section> instead of <div>, which I find to be a more pleasing result.

And no worries, I’ll pick this up again whenever you get a chance to update!