I’m using basically two font families, Palatino (No Style) and Menlo (Code Block, Code Span). I use occasional boldface and italics in No Style, and occasional italics in Code Span. When I compile to mobi, epub, pdf, or rtf, there are no italics in Code Span–everything is just plain.
I do have Menlo italics on my computer. I’ve looked at the HTML and there are no or tags where there should be.
I couldn’t say, with regards to rich text formatting, as that all works fine in my simple testing of it. But I likely was not using the same compile Format you are and other potential settings. I’d give it a shot with simple “Default” compile format settings, which doesn’t overwrite text formatting at all, to start with. At the moment it’s impossible to say whether the problem is at the source, somewhere in the middle, or at the end (when viewing the file in another program entirely).
As for ePub, that’s going to be interesting because you’re using a “real” code block in that case. You’ll note in the output that it is using
… elements, which means if you have tags in there they would print verbatim—surely not what you want.
So you’d have to go into your Format settings, under HTML elements, and switch off the code block/span styles. Now they will act like ordinary styled paragraphs. You’ll probably want to add some CSS to the appropriate pane, to ensure the .code-block classed paragraphs look like code and not ordinary prose.
That said, ebook HTML is derived from the RTF, initially, so until you get the underlying problem resolved, you shouldn’t see any effect in the epub output.
Not sure how much work it would be, but overall you might consider using character styles for whatever it is you are doing, instead of raw italic font settings. Although in theory the latter should be robust, character styles should be even more so, and will provide additional flexibility in output (say most ebook reader’s fixed-width font doesn’t have italics, you’ll need an alternative).
Thanks for your post; you’ve definitely given me some more avenues to explore.
I created a new project, pasted some text into it, pasted some program code into it, and styled the code as Code Block. I’m happy to say that I did get a
block for it. This is not what Code Block does in the book I have written, though; instead, every line is in
tags. I have long wondered why Code Block didn’t just give me a
tag, so now I can conclude I’ve messed it up somehow. At least, that’s a start toward fixing it.
You said that “You’ll note in the output that it is using
… elements, which means if you have tags in there they would print verbatim—surely not what you want.” Actually, tags within
blocks work just fine; I’ve been doing this for years, and just checked it again. In my simple test file, though, Scrivener definitely does the wrong thing; code in italics is surrounded by single asterisks. I’m not a markup user, but I recognize this as markup for italics, which has no business being in the HTML generated for epub files.
Could be you started from scratch with your settings, rather than the Ebook format. I’d have to double-check, but it could be vanilla “Default” doesn’t have any built-in style definitions, and thus nothing mapped to HTML.
Ah, good catch. I’m so accustomed to Markdown and LaTeX, which have true verbatim environments, that I forgot HTML doesn’t really have such a thing.
You’d think so, but in this case we would expect them to be here, and you are in fact a Markdown user, if indirectly, as Scrivener uses Markdown to generate the HTML for your ebook source. It is far cleaner than the stuff you get from raw RTF conversion, and for another it is HTML5 which is needed for ePub3, which Apple still hasn’t gotten around to adding a converter for (yeah, seriously). Trivia aside, I do not think that disagrees with the sum of what you are saying, that this odd corner could probably be handled better, but it could be a bit awkward to fix it given the nature of the conversion.
What is happening is that Scrivener is converting your italic text to Markdown italics, which would ordinarily later get converted to HTML, but they end up in a Markdown code block as well, which as previously discussed is in fact fully verbatim—hence raw asterisks in the output. So that in and of itself also presents a problem if we pre-converted the asterisks, since Markdown’s code block environment is a true verbatim, it strives toward that as an end result as well, meaning the conversion engine will be escaping entities, meaning you will get in the output.
Given the number of traps here, I’m starting to think the best workaround may be to use Scrivener’s Treat as raw markup setting in the Styles compile format pane, for both the modified code block and the emphasis. While this would let you type raw HTML in directly into the editor, you can also supply prefix/suffix values into these styles to keep the editor clean, in this case. There are two limitations I can see with this:
You can’t have code blocks with empty lines within it, owing to a peculiarity in how Markdown handles raw HTML insertion.
Indenting isn’t going to work how you want, as it looks like Scrivener collapses whitespace even in a raw markup field. That should be easier to fix, and unless I’m not thinking of a contingency, probably something we should not do.
I’ve attached an example of how this can work though, under the right circumstances, and a second example further down where things break apart. In the second document, I use native code blocks, and you can see the result isn’t at all what you want, even though we’re inserting the elements ourselves with the style, MMD escapes them.
You already have. But like I say, this one may be a tricky solve for multiple reasons. styled_code.zip (85 KB)