[LH3945] getting a custom style to show up in epub

Hi!
I’m trying to compile a manuscri;t to epub on windows beta 21.

I have a custom style, which I’ve used in the manuscript, and which I’ve added to the ebook compile format.

The style doesn’t show up in the epub version. I looked at the html code, and there’s no sign of it there.

I’m not sure if this is a bug, or if I’m doing something wrong.

Any advice would be greatly appreciated.

Thanks!

Font and font size is set by the ebook reader software, customizable by the user. Locking it is tricky.

Thanks for your response. I suppose I wasn’t clear enough. This isn’t about fonts.

My question/problem is about a paragraph style, which I have successfully added to the editor style list, and which works fine there. I have also added it to the style list in my ebook compile list, and have added the appropriate css for it in the custom css section.

But when I compile an ebook, scrivener ignores this style–by which I mean, the appropriate paragraphs in the html do not contain the class for this style. Their tags, in fact, are identical to any other paragraph.

So my question is, how does one get scrivener to include a style class in the compiled ebook html?

I’m quite sure scrivener is designed to do this from the documentation, so either I have done something wrong (most likely) or I’ve uncovered a bug (less likely).

If anyone knows how this works, and what I may have done wrong, I will be most grateful.

Topic moved to beta forum, as the release version doesn’t support styles.

Katherine

Thank you. I don’t really know my way around the forums, yet.

I’ve experimented a little bit in Calibre, and find that the style works perfectly if I insert it in the html manually. So the CSS is working. The problem is that it’s a style I use quite a bit throughout the manuscript, and it just isn’t being inserted during compile.

That is to say: the class isn’t being inserted in the

tag.

I just noticed that when I check the style in my compile format, It doesn’t display the CSS class name, even though I have saved it with the class name entered.

Does anyone know if this is normal, or if it may indicate something about the problem I’m having?

Thanks for any responses.

Are you having this trouble with the default paragraph styles as well, or only with your custom style?

Only the custom style.

Have you created a custom compile setting for e-pub that translates your custom style into the appropriate html tags?

Sorry if I’m barking up the wrong tree here, since I don’t do e-pub compiles, but as far as I’m aware, Scrivener doesn’t assume that a custom style is to be translated into a stylesheet style of the same name, as far as I’m aware. Until you tell it “this paragraph style should add before the paragraph, and </html code> after the paragraph”, Scrivener probably doesn’t know what to do with your style.

If you are compiling to a word processing format that understands word processing styles, that’s a different story, since it’s literally the same kind of thing.

Note that I could be way off base here; my experience with custom styles and plain-text markup has to do with my LaTeX experimentation, so if I’m wrong about how Scrivener styles (don’t) translate to HTML style sheets, please ignore this post.

First of all, thank you for responding.

The epub compile format has a styles section, which (appears to) allow you to assign a class to your style. It also has a CSS section, which allows you to write the CSS for that class. I’ve done both.

The CSS appears to be working fine, because if (after compiling) I go into the html code and manually insert the class name into a paragraph tag, I get exactly the style I intended in the resulting ebook.

The problem seems to be that Scrivener is not inserting that class name. I don’t know if that means that I’ve done something wrong, or if it’s a bug that hasn’t been fixed yet.

But while we’re talking, can I ask if you are having any luck compiling MMD to Latex with this beta? I can’t seem to get a clean compile for that. It marks up the <!-- comment code, then changes all my backslash codes to \textbackslash{} and other stuff. Any hints, there?

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:

  1. You style some text with a 2cm block indent, 1.5 line-height and italic text.
  2. In the editor, you create a style called “Monologue” that saves paragraph & character formatting.
  3. 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.

Thanks Amber, that was really helpful.

So I have a tangential question. I had assumed that “release candidate” meant that everything was done, and that anything that didn’t work was now a bug, or a mistake on my part. (That’s just an explanation of my process–not a criticism)

I would like to help out with spotting bugs, particularly in the compile process since that’s what I’m working on anyway, but I’m not sure when to report something or when to just assume it isn’t implemented yet.

Is there a rule of thumb I should be employing, to decide whether to bother you guys when I can’t get something to work?

Hi Ken,

As long as there’s not a thread that already has a number assigned in the title, feel free to go ahead and report it. It’s possible that we already have the issue recorded, but better safe than sorry :slight_smile:

I’ve marked this one down as filed. The bug is that CSS class name isn’t being saved at all, let alone passed on in the compile. Hopefully with this bug fixed everything will work as you expect. But if you see this number listed as fixed and you still have issues, please post again.

Thanks!