To clarify the intended behaviour (all of what I’m about to go into doesn’t work yet, so don’t really follow these steps expecting to see what I describe—this is what you’d see in the Mac version), in fact all of this should be fully automatic, with you only having to step in if you want to do things above and beyond, or simply differently from, what Scrivener does automatically. Here’s a simple case:
- You style some text with a 2cm block indent, 1.5 line-height and italic text.
- In the editor, you create a style called “Monologue” that saves paragraph & character formatting.
- You compile an ePub with default settings, stock “Ebook” compile Format.
Result: the text, being a paragraph style, will be in a
element classed as “monologue” automatically (it would use a classed for character styles), and the stylesheet.css file will be generated with a .monologue directive containing:
.monologue { margin: 0rem 0rem 0rem 4.72rem; text-indent: 0rem; line-height: 1.5em; font-style: italic; }
So you don’t have to know thing about HTML or CSS to get custom styles piped semantically through the system. The settings you’re looking it here are all where you can go if you want to take things a little further, or customise the result:
- You can manually add a “Monologue” style to the Format’s stylesheet, which will then intercept any like-named styles in the project and transform them. At a basic level you could decide to make the text green here as well, but only on output.
- If you switch over the CSS pane at this point, you could search the Default Stylesheet for .monologue and find it is now updated to include a color attribute along with the rest.
- Jumping back to the Styles pane, you can give “Monologue” a class name, let’s say “sarah-monologue”, and now back in the CSS pane, the selector will be changed to .sarah-monologue. So if you know the logic behind how it names styles automatically, you shouldn’t normally need to do that, but this is a way to override the automatic class name and make it predictable, or conform it to an existing stylesheet you’ve already developed.
- Then we have the Custom Stylesheet, which can be appended to the default (which is a combination of the Format’s settings—the checkboxes you tick, section layouts you create and their settings and so forth—and the styles you add to the Format’s stylesheet). This will be tacked on to the end of the stylesheet.css file, and so taking advantage of how CSS works, you can either completely override .sarah-monologue here, or just add one new attribute to it, leaving the rest as established by the settings.
- Incidentally, one other approach that should work is a system that lets you define your own HTML from the ground up. Say for this style you really need a div with p elements in it, because you want to draw a box around the whole thing. That’s where the Treat as raw markup flag and the prefix/suffix system would come into play. Unfortunately the markup setting doesn’t impact the prefix suffix text, so it escapes whatever HTML you type in there. Otherwise that would be a way of saving yourself the step of having to add the HTML in yourself after compiling.
So you can see, we mean this to be a system whereby it can work for people that know nothing about this stuff—but if you do know what you’re doing, you can get in there and insert Javascript if you really want to. This is where compile Formats can really start extending Scrivener by generating novel features through its various hooks for doing so.
Yes, there may be one or two bugs (or incomplete implementation in one case) going on here—it’s hard to tell as one may be obscuring the other. One is that the HTML generator isn’t classing things semantically but creating serialised classes like word processor output would. There’s a lot of work there left to do. The other problem may be a style related bug in general, where formatting overrides at the Section Layout level essentially blow away all styles. That’s a bug you’ll find in RTF (from which the HTML is generated) output. Needless to say, both of these and all of the above are some of the big blockers that made a Friday release impossible.
We’re using 6.4 in the beta now, so custom LaTeX should be escaped using the new system, HTML comments no longer do anything but HTML comments:
`\begin{stuff}...\end{stuff}`{=latex}
By the way, the stock LaTeX-based compile formats have an entry in their stylesheets called “Raw LaTeX” that will handle the backtick syntax for you. Just add a character style of the same name into the project, type in the code, and mark it up. Only thing to watch out for is the bug that causes styles on the ends of lines to include the paragraph break (which breaks backtick syntax since it would end up falling over two lines).
It’s a bit of a wrestling match at the moment if you’re needing to compile, sorry for that.