I’m writing a technical book and there are several places I need to display HTML code. The HTML displays ok but needs better formatting. Meaning, I’d like it to stand out from the main book content better. Right now, the HTML code is the same font face and size as the regular content, causing it to blend in.
Anyone have some suggestions on how I can better format HTML and have it stand out more?
Formatting is controlled by CSS, not the HTML.
So what are you doing with the HTML output? What application are you going to use? Web? PDF? Other?
One great application is Marked2 (you can buy from developer, or very soon on the App Store). You can drag a Markdown file onto it and it will convert to HTML. Plus you have the choice of a lot of CSS stylesheets to use, or to create your own.
I don’t know, however, how you’re creating your Scrivener document. I tend to use Markdown or Multimarkdown which makes it easy to deal with issues like you describe.
If you are exporting to Word (cringe) or something else, then hopefully other folks have more useful suggestions for you.
I’m not sure what you mean. I’m not doing anything with it.
I’m exporting to epub and mobi.
Have you tried using a fixed-width font for the code blocks? In combination with a Preserve Formatting field to keep the code block from ending up like body text when the compiler overrides formatting (if it does), this should work nicely for e-books. Courier is a good choice, as it will definitely set the “monospace” request in the CSS. Not all fixed-width fonts will trigger that result in the output CSS generated by Scrivener (well, technically by Cocoa).
If I use Courier on the HTML, it looks no different in the epub/mobi. I don’t think you can use a mixture of fonts in epub/mobi? The user controls the font.
Yes, that is ordinarily true (unless the reader has the “Publisher Font” option enabled), but a good number of e-readers will make an exception for the “monospace” CSS request (which is just a general request for any fixed-width font, the display mechanism gets to choose which precise font family will be used for display), since it can be useful for stuff like this.
What are you using to verify the results? Perhaps the software you are using to display the ePub is the one with the limitation? I have just run a test and using Courier 12pt in a Preserve Formatting field will display properly in Calibre, Sigil, Adobe Digital Editions (and thus should work fine on most ePub e-readers on the market, Nook/Sony/Kobo) and iBooks (Mac). I didn’t test Mobi specifically this time, but I’ve done so in the past and the method works across all Fire and e-ink models the last I checked.
I’m testing in the Kindle App.
Okay, I’ll give Kindle Previewer another spin in a bit and report my findings.
Cool. Thanks.
Okay, it works fine in Kindle Previewer, tested with Paperwhite, DX and all Fire models. It also works fine in the Mac Kindle e-reader software, too. I’d suggest making sure KindleGen and Previewer are up to date. Otherwise the only problem is in implementation. Can you enable the source file option in the KindleGen compile option pane, and then examine the HTML files that contain the test code blocks with Quick Look to see if they appear fine at the HTML/CSS level?
I also checked Kindle Previewer and same results.
How do I access KindleGen?
I just checked your reply on the website and see the pic. How did you get that look in Scrivener?
It’s hard to say, since KindleGen can be placed wherever you want. Search for “kindlegen” with Spotlight, you should see a search result that has an icon that looks like a Terminal window. Cmd-click on the search result to locate it in Finder, and read the “Release Notes.html” file in the docs/language subfolder. I’m testing with “2.9 build 0523–9bd8a95”.
If you mean the blue box, that could be the crucial missing ingredient. Select the HTML code in the editor and use Format/Formatting/Preserve Formatting. If you don’t have that, and are using format override to clean up the text when compiling, that would explain why it isn’t working, as the compiler is just knocking the text back to some default body format. Preserve Formatting tells the compiler to leave this text alone.
Yes - after doing preserve formatting, I seem to be making some progress. But there’s a lot of indenting that I’m not sure where it is coming from. I don’t think it is specific to the HTML section. I have paragraph indents in the Kindle App but they aren’t there in Scrivener.
You can also see how far over the tag has moved. Do you know what might be causing these indentations in the output file?
Maybe check your tab stops with Format/Options/Show Invisibles enabled. Apple is going to export indents as a literal tab character wrapped in a span that is CSS marked to show as pre. Thus, you should get roughly the same amount of space out of a tab that you would get if you used a
environment to show the code block—it won’t in my experience, have anything to do with your tab stop settings in Scrivener—tabs don’t really map well to HTML, as a concept, as you probably know. So setting them to roughly match the Kindle output, in Scrivener, may be beneficial, but not essential.And again, that option to export source files can be really handy for figuring out what is going on at the HTML level of the e-book. You should be able to see exactly what is happening with the indents by examining that corresponding HTML file. Incidentally, you can also use that source folder create your own hand-tweaked book, which is the real reason for the feature. Just open the .opf file in Kindle Previewer to turn that folder into a Mobi. If you find that hand-tweaking the CSS files after compiling gets the best look, that’s how you would do it.
Note once you get a code block working the way you like, with the font, tab stops and Preserve Formatting, you can turn the whole thing into a preset. Use Format/Formatting/New Preset from Selection.
Okay, one thing you should be aware of is that this method Apple uses, although it is a perfectly valid and legitimate use of HTML and CSS, does not work properly on all readers. If you’re just focussing on Kindle right now, you should be fine. This method works on I think all Kindles, definitely all modern models. I know only of conflicts with some potentially older Nooks. It will treat the whole line as
if even a part of it is spanned that way, so word-wrap is disabled for any line with a literal tab character in it. We periodically get reports from people that use literal tabs to indent their paragraphs.For your purposes that might be okay if you keep line lengths short, though.
Thanks!
I have turned it into a new style. Is there a way to create a shortcut key for a style?
One thing I have to do is check “As-Is” for all of my pages. Otherwise, the formatting has no effect.
Yes, we have a how-to page on setting custom shortcut keys.
That shouldn’t be necessary. What do you mean, even the blocks with Preserve Formatting get reformatted if As-Is isn’t checked? Maybe check behind the Options button in the Formatting compile option pane. Normally they are all off, but there are some options here to restrict all what Preserve Formatting does.
I’m not sure which Options button you mean. In the compile window, I click “All Options”. Unless I check “As-Is” for my pages (not chapters), the formatted HTML is lost.
In “All Options” of the compile panel, select Formatting on the left, then click the Options button in the upper right of that pane. That pulls up a sheet with various options, including restrictions for what Preserve Formatting actually preserves. You should leave that unchecked, so that everything is preserved (within the limitations of the compile format).
There shouldn’t be any need to check “As-is”–the whole point of the Preserve Formatting block is to essentially mark just that text “as-is” while allowing the rest of the document to be formatted according to the compile settings. Normally if you don’t want to reformat any of your documents, you just leave “Override text and notes formatting” unchecked in that Formatting pane of compile. “As-is” is intended for rarer use, where normally you’d be overriding formatting for that particular type of document but in this special case you want the document exactly as it appears in the editor. Documents marked “as-is” always compile only their text, regardless of what else you normally have set–e.g. if documents are set to compile both title and text, those marked “as-is” will only compile the text.
So long as you have “Preserve Formatting” on your code blocks and you aren’t accidentally restricting Preserve Formatting to only preserving certain aspects of the formatting, you should get the same results for that specific text with and without “as-is” enabled.
