Text Options and "As-Is"

Exporting to Markdown, I’m enabling the “paragraph spacing” option (awesome!). I’ve checked one of my document “as-is”, but it still gets processed. This seems like a bug to me.

Brett

Hmm, I’m not sure about this. I could change this with half a line of code, but before I do I’d like to see if anyone else has opinions on this, because I can imagine this being debatable. For instance, scriptwriters using plain text format for export may still want plain text formatting in “as-is” files.

I think you have a point, but if anyone else wants to chime in, now’s the time!

Thanks,
Keith

Yeah, I’m not sure about this one. This option doesn’t, to me, seem to be about formatting; it’s about the conversion of RTF formatting to syntax. It’s letting you take a block indent and turn it into a code block; or a 12pt after-paragraph spacer to a double-newline, and as such is a convenience when working with pre-existing rich text material. Considering the sole purpose of as-is right now (title removal), if one were using this option to avoid massive editing to convert their old RTF drafts to double-newlines and such, they certainly wouldn’t want a big blob of text in that document just because they didn’t want a paragraph. They would then have to alter that one document to double-newlines and physical tabs and always remember to double-tap enter while working in any as-is document, while single-tapping in any other document. That result doesn’t feel right to me. It would be pretty annoying to have to keep track of whether or not you are supposed to be double-newlining or not—all because you just wanted to dump an auto-title. Imagine this in scrivenings mode; it wouldn’t be immediately obvious which documents were which.

What is the situation that you were wishing to use as-is against formatting conversion for, just out of curiosity? I’m of the type that doesn’t really use the formatting conversion. I prefer to use formatting for artistic or functional embellishment, with the knowledge it will all be wiped out. So I’m not perhaps in the right mind-frame to see where you are coming from with this.

Yep, it looks like this option could go either way, depending on how you’re interpreting ‘as-is’.

My situation is a bit warped. One thing I’m playing around with now is dumping my document out to markdown format, postprocessing it for bibliographic data, and then getting pandoc to convert it to PDF, or ODT. Pandoc (unlike multimarkdown) is being actively developed, and has some nice features. Unfortunately, it does not support multimarkdown’s Metadata, so I was trying to use a single as-is document to do that. But, of course, I don’t want that double-spaced.

This relates to my earlier question about plugins. One place plugins would really be nice is at the compile stage – maybe something as simple a being able to call a script of choice (text-processing in objective-c - no thanks!). Hm. It probably wouldn’t be that hard to write a python script to do it directly from the rtf/xml files.

In any case, you shouldn’t change it for me. I honestly thought that it might be a bug. But it’s more complex than that.

Actually, on the notion of plugging in code to the compiler, there is already a way of doing this, and it simply involves understand how Scrivener manages the MultiMarkdown pipe. It basically sends STDOUT to a pre-defined script, and then uses STDIN to capture the resulting conversion, then dumping into the user’s specified file name and location (or assembling a folder structure if necessary, for media).

So all you really need to do is insert a script into the spot that Scrivener calls in the UNIX system, make sure you output a document to STDOUT, and Scriv would be none the wiser. This is quite easy to do if you install a custom MMD installation. You can just swap out one of the existing primary conversion scripts for your own Python code (yes they have a .pl extension, but with a proper hashbang that shouldn’t be a problem) that handles the Pandoc workflow.

You can test this by placing a script in ~/Library/Application Support/MultiMarkdown/bin/ called mmd2RTF.pl. I’ll use Ruby since that is my weapon of choice:

[code]#!/usr/bin/ruby -w

puts “Ha ha, I ate your document!”[/code]

Compile to MMD->RTF, and you’ll get nothing but “Ha ha, I ate your document!”. Make sure the executable bit is set, otherwise you’ll get a stalled compiler.

So, once you’ve got that, take it and run. You could process out the meta-data with Python instead of trying to hack it out with Scrivener.

Awesome! An invitation to hack :slight_smile:

Thanks for the info. I’ll let you know how I go (though it looks like it might be few days before I get the chance).

Brett

Too easy! I have a drop in replacement for multimarkdown which now uses pandoc (for RTF).

Problems: I’d like to be able to write a PDF and an ODT as well. But I can’t change the default extension in scrivener (sensibly!).

There is real scope for a very simple Compile plugin here. Get your users to do some work for you :slight_smile:

Oh yeah, now I remember that. You have to change it after you export, or set up a Hazel script or something else that fixes .pdf.rtf files.

This is interesting. I’ll have to look into Pandoc when I get chance.