Tab in MD compilation

Scrivener Markdown & LaTeX
,
1

How do I preserve first-line (only) tab on each paragraph in the Scrivener Compile settings for MultiMarkdown? I can make the section layout have a first-line tab, but it won’t copy across to the compiled MD file.

I’ve seen lots of web chat saying there’s no TAB in MD, but am I stuffed here?

2

There’s no concept of tabs or indents or any of this kind of design features in Markdown. Because it’s not meant for page layout. Would you send your readers an MD file?

(So, either you compile to a format that supports such features out of the box, e.g. PDF, or you use this MD file as the starting point for further processing, and that’s where and when the design work happens.)

3

Thanks for your response.

Yeah, I get that, but I would have thought that since (1) Scrivener already knows I want a first-line tab for each para, and (2) MD supports HTML, so the Scrivener compilation could have inserted three or four   at the start of each para, I sort of hoped that the fact that Scrivener wasn’t doing that was simply because I wasn’t pressing the right buttons in Scrivener compile. But you’re saying I didn’t miss anything, I think.

I suppose I could post-process the MD file with some clever RegEx command that did the necessary for the whole file in one fell swoop, but I’m still puzzled as to why Scrivener doesn’t automatically do it, or at least provide the option to do it.

4

Sorry … that should say “three or four HTML non-breaking-spaces” …

5

PS: Sorry, I missed replying to your question “would you send your readers an MD file?”
The answer is YES, sort of.

This is for a case where I’m uploading the text to a WordPress website. WP JetPack has an MD block that auto-converts MD to HTML with some built-in CSS styles, so I thought it might be quicker than my compiling direct to HTML in Scrivener and then doing a load of CSS post-processing to style it.

Perhaps I was trying to be too clever and should have stuck to direct CSS and HTML.

1 Like
6

[This thread is mostly about stuff I don’t mess with, but…]

It seems like you could tweak your compile settings so as to have compile do a Replace of those initial tab characters with some suitable HTML code.

7

One of the big advantages of using Markdown to generate your HTML for blogging software is precisely how clean and devoid it is of any opinions on how it should be displayed. Those using Scrivener’s stock HTML output have a massive tangle of extremely opinionated CSS rules (stuff like indent settings, fonts, font sizes, line heights, paragraph padding, kerning…), so much so that it if you paste it right into a blog it stifles the blogs native look and feel. As you noted above, something you’d have to deploy a bunch of messy RegEx to clean up. I wouldn’t recommend anyone go down that path. Scrivener’s native HTML is better for those that have no clue what any of these abbreviations mean and just want to upload an .html file that looks somewhat like they told the compiler to make it.

If instead you have this, which is more like what Markdown is going to give you:

<h2>Article Subheading</h2>
<p>First paragraph</p>
<p>Second paragraph</p>

Then it is entirely up to the blog’s theme and overall style settings to make that look the way it should. No processing, no post-processing… you’ve just got some CSS in WordPress’ setup somewhere that looks something like this:

/* Only paragraphs following other paragraphs are indented */
p { text-indent: 0 }
p + p { text-indent: 0.25em }

So it is for this reason that I don’t really include much by way of examples for HTML formatting in Scrivener’s Markdown compile format list. In most cases people want that option because they either have their own CSS or want to plug the HTML into some system that does.

LaTeX compile formats, on the other hand, you’ll find lots of examples. I’d like to provide DOCX/ODT examples, but limitations in the compile system make that difficult (to style things properly there you need template files, and a reliable means to point at them on the user’s system). Plus on the Windows version the Processing pane was never even finished, lacking an embedded script facility, meaning I couldn’t even do a trick like packing binary data into a self-extracting script. Plus, its debatable how much of an “example” that would be to anyone without programming experience. Anyway, I digress.

Yeah, I get that, but I would have thought that since (1) Scrivener already knows I want a first-line tab for each para, and (2) MD supports HTML, so the Scrivener compilation could have inserted three or four at the start of each para, I sort of hoped that the fact that Scrivener wasn’t doing that was simply because I wasn’t pressing the right buttons in Scrivener compile.

So, couple of things here:

  1. Scrivener works in a fundamentally different manner when you compile via one of its MMD or Pandoc settings. It’s better to think of it as a plain-text editor almost (though that’s not really the case in many important ways, that’s a better place to start from than thinking things like “Scrivener knows I want a first-line tab”—for this, no, it does not).
  2. Whatever you just did there to “indent” is not how you want to do indents in an HTML file (or pretty much any kind of file). The example I gave above should illustrate what is more like what you want to see and do. So even if Scrivener did have higher level “indent paragraphs following X” type controls in the Markdown workflows, it would not be converting literal tab characters to non-breaking spaces or anything like that. It would be most likely generating CSS and inserting that into the Pandoc/Markdown metadata block so that it can be inserted into the HTML file’s <style> block, or generating a sidecar .css file along with the .html.

But we don’t, because that is a rabbit hole we don’t want to go down, and in most cases MultiMarkdown and Pandoc already have an excellent infrastructure for formatting the raw .md file into something pretty, especially for HTML. Reinventing all of that doesn’t seem like a good use of time.

To conclude, I do think you’re on the right track with using MD here, just expect less formatting from it, because in most cases like WordPress, less is more.

So to wit, I would just strip them out if anything (though it doesn’t really hurt anything to leave them in as they will be ignored by most browsers; shown as a single unwanted space at most). It’s better to let the WordPress theme handle indent policy, or add the CSS to the HTML file to let it handle that, which you can do by adding an “HTML Header” metadata key to your compile Format’s Metadata pane. But I would only go down the latter route if I was making a simple static site. For any decent CMS or similar, it’s going to want clean HTML and minimal CSS.

And in fact there is one important reason you would want to strip out prefixing tabs for MD files, and that is because such means “this line is a code block line”. But I would go about this by using the Edit ▸ Text Tidying submenu to strip leading tabs out of the source, rather than a Replacement. As I say, in nearly every case, rich text and Markdown alike, that’s not what you want for indenting paragraphs anyway.

2 Likes
8

Great post, AmberV. Very helpful!

Once you pointed out that Scrivener was not going to do any formatting for MD, the solution was really easy, as you indicated – just a few lines in ‘Additional CSS’ in WordPress and making sure that MD’s requirement of a blank line for each a new para is met with a quick Find & Replace. Helpfully, the JetPack MD block in WP creates a <div> with a unique CSS class, so I just adjusted text-indent and I fiddled a bit with margin-top and font-size in that class, and that was it . Now it looks just right.

A lot easier than tedious and time-consuming fiddling with raw HTML to get it looking good.

Thanks again for your helpful advice.

1 Like
9

Oh, I notice I can avoid the need for Find & Replace to insert the blank lines at the end of paragraphs by selecting Convert Rich Text to MultiMarkdown under Settings in the Compile window. So, even easier … :+1:

10

There are two ways of doing that. The option you mention is a bit more hardcore in that it is not designed for any Markdown formatting at all in the writing process. It’s a switch meant for people that don’t write using it, but would like to take advantage of its better output quality. By and large it will escape all punctuation that could be confused with markup. There are ways around that, using styles to pass-thru markup, but that can be a bit of a bother unless you seldom use syntax. For myself anyway, one of the major draws of writing with Markdown is being able to format my text and write at the exact same speed, without stopping and switching to a mouse or having to use menu commands and shortcuts.

The other approach is to tweak two settings in one of the built-in compile Formats, like “Basic MultiMarkdown”, which are largely set up to convert “word processor” style paragraphs to Markdown double-spaced. You just have to turn it on, basically. Here are some instructions written up for a LaTeX template user, so ignore that part of it—the LaTeX project template has the same exact setup in its default compile settings.

And if you’ve already got a format of your own that is more developed, this post here describes how to make this work from scratch. It’s a very simple adjustment, and if that is your main issue with writing in Markdown, it’s a pretty effective way of doing so and gives you a lot more flexibility in how much Markdown you want to use, than the global RTF conversion switch.