In particular the last line? Is it “hard-wired” into the EPUB compile format Scrivener? I couldn’t find any setting in the Compile Format Designer to get, for example, the text-indent of .heading to zero.
In Sigil, there is a function to clean the CSS stylesheet of whatever is not referenced throughout the book.
You could run that function, and if the line is still in the stylesheet afterwards, you’ll know it is there for good reason.
After that, you can edit it to be the way you want in the stylesheet (Sigil), or in the CSS panel of Scrivener.
To take a guess, I’d say perhaps those come from your section layouts, with this setting checked in the CSS panel:
(It is just a guess. I don’t actually know.)
There are usually extra lines in the stylesheet when I compile to epub.
I’d say: use that function I screenshotted above, and then just forget about it.
– even when I deactivate the checkbox below the CSS panel. And because it is appended at the end of my custom CSS the only thing I can do is adding an anticipating !important override rule to my custom CSS …
No big deal, but I would definitely like to understand where the rule is coming from … I couldn’t find any section layout resembling that weird text-indent: 1.25rem or the font-size: 0.92 rem. Seems a bit weird. 0.92 x 16 pt is something like 14.72 pt?
Search through your xhtml files in Sigil for “heading”
It’ll show you what it pertains to.
[EDIT] Actually search for “heading” and not “.heading” (my bad), since in the body xhtml files the class is referenced only by name. No period before.
Hm, I know where the class “heading” is used but I don’t know where the CSS rule Scrivener applies to that class (because I don’t do it) stems from in Scrivener itself.
In fact it is the class of the main wrapper div of each and every .xhtml file:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xml:lang="de" lang="de" xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
<meta charset="utf-8" />
<title>5 ~ Zwischenspiel mit Logos</title>
<meta name="Generator" content="Scrivener for Windows HTML Writer" />
<meta name="ScrivenerVersion" content="3.1.4.1" />
<link type="text/css" rel="stylesheet" href="css/stylesheet.css"/>
</head>
<body>
<div class="heading">
<h2 id="doc17" class="heading-page-padding"><br /></h2>
... more content -..
</div>
</body>
</html>
The div wrapper with class “heading” is really part of every body file beyond the front matter files … and contents.xhtml of course … sorry that I didn’t copy from a body file, would have been clearer.
I just compiled a project of mine to epub3 through the “ebook” compile format, and I don’t have this “heading” div class.
Perhaps you could try the same. See if it originates from your project or from the compile format you are using.
P.S. Having just compiled to epub3, I now see the header of the body files looks more like the one of the contents file.
I think I was earlier unwillingly comparing with an epub2. (Maybe…)
It made click in my head now and I found the “culprit”: In the original Ebook format and my copied project format as well the section layouts “Heading” and “Heading (bordered)” have the associated class “heading”. And I linked “Heading (bordered)” to one of my section types.
This section type is assigned to a binder folder which has the only function to hold the scenes or passages of a chapter and provide the chapter title. That’s the reason why the div wrapper wraps the whole content in a .xhtml.
And because we have a heading here the column “Text” is deactivated in the section layout definition (by default in the original Ebook format and in my copy as well).
But if you activate the “Text” option it and look at the associated formatting of the text paragraph you can see that there is a text-indent (= indentation for the first line). That gets translated into the CSS div wrapper then. (I set the indentation to zero now.)
I guess the default text-identation for the Text part of a heading that could translate into CSS this way should be set to zero in future releases though … (@AmberV, I link you here,. maybe you could have a look into this. It’s not bug but a bit of an inconvenience.)
Did it affect anything? (as in a bug, somewhat), or was it more like a ghost?
Did it become the indent of something else?
Why did it matter to you in the first place?
Because it was added to my custom CSS as last lines by Scrivener it affected the text-indent of any .xhtml file because they are all build this way (as I described earlier) and had all the div wrapper with class “heading”.
That means that any HTML element that hadn’t a specific overrule for text-indent was affected (as along as it has the CSS property “text-indent” of course).
Because I couldn’t find the origin of this rule I had to unnecessarily overrule the indentation of a couple of other elements who showed up that unwanted indentation behavior.
Basically what it means is that if a user unknowingly customizes his/her compile format to have two section layouts of the same name, the whole of the two layouts will end up looking the same once compiled to an ebook. (Which, though undesirable, still would somewhat make sense). – Did I get it right?
It has nothing to do with two section layouts having the same assigned CSS class. That was the case, but the effect is the same with different names.
The problem:
You have a section layout which is only set up to use the title text.
Thus the formatting windows only shows the title.
But there still is a hidden formatting for the text part of that layout. Any settings made here translate into the CSS rule for that section layout.
If you happen to assign that section layout to a section type which is assigned to a binder folder than any documents within this folder will have a div wrapper with that class wrapping the whole content.
Then any CSS settings which stem from the HIDDEN text part (hidden in the Compile Format Designer!) of the section layout are applied to every HTML element within the div wrapper. (If of lower CSS specificity.)
And you cannot detect the source of such a rule because the text part is HIDDEN.
I can’t explain it any better, sorry.
This would be a very rare event of course and no big deal, as I said. Just something to have back in one’s mind if something weird is happening.
Sorry for taking a while to look into this. There are multiple issues causing problems here, and it looks like you’ve identified most of them. What should be happening:
Section Layouts optionally generate a classed <div> around the content of the layout if a class name is assigned for it, in the Section Layouts: Settings tab, with CSS class name.
When those conditions exist, nothing special should be done with regards to special CSS output for that div.class-name. It’s just there in case you want to do something with it. Thus no .class-name CSS should appear anywhere in the output.
The one case where we might want to see that is if the Layout defines custom body paragraph formatting, but even then it shouldn’t be assigning it to the .class-name div, but rather each paragraph would then be different from the default paragraph formatting, and thus have a .ps# style serial class created for it. A bit messier than a human designer might do for any of this, but such is the way of machine-generated HTML/CSS from an RTF source.
The Layout divs should not enclose content generated by other Layouts entirely. Each layout should have its own div if there is a class name given to it. For example a typical chapter might have this stack of sibling divs:
Your assessment is correct, passive background text formatting is being output as CSS for each layout’s div, and since the HTML output is not correct (all layouts end up in the ‘.heading’ div and none of the other layouts even generate divs), we end up with the inactive passive text formatting for a Layout that doesn’t even print text being used to format other layouts’ text.
The simplest solution (on our end) for fixing the one main problem is to remove the code that is printing section layout div CSS. That shouldn’t be there anyway, and even if it should be there, it definitely shouldn’t be coming out after the area where user CSS is injected.
There isn’t a really clean work-around that resolves all of the above, since even the HTML structure is incorrect, but one can at least open the .epub and delete the div.class-name stuff from the end, to at least exert their own control over the formatting, to what limited ends one can.
Frankly, I don’t use any of Scrivener’s .epub output myself. I use Pandoc’s ePub generator with Scrivener, which is a million times cleaner and easier to work with if you know CSS. That’s me though—I’m the one that designed most of this stock CSS, so staring at a blank CSS input field in the compile format designer with no GUI at all for chaning how anything looks doesn’t phase me, and is if anything more welcome that tangling with a GUI that generates CSS from checkboxes and such.
It’s something to consider though, if you are of a similar inclination. You could even copy and paste the CSS out of the generated stylesheet.css file and drop that into the Pandoc Settings compile format pane with adjustments to make it work with Pandoc’s cleaner HTML output.
Thanks for the detailed explanation and the pointer to Pandoc’s ePub generator. I’m not doing so much ebooks though, and Pandoc would be a new tool as well, so I’m not sure if that’s really an option for me, but will keep that in mind!
It perhaps sounds as though it has more weight than it would. It is more like choosing a different conversion engine for Scrivener to use than learning a whole new tool. The main difference is a stronger reliance upon styles for unusually formatted text, which isn’t a bad habit anyway.
