External File Sync: basic markdown?

There are some devices/platforms where editing RTF files in dropbox isn’t really supported, for example my android phone. But using plain text can remove some formatting, such as bold & italics. In my testing, some formatting like highlights and comments don’t show up in the text file, but then is preserved even when the text file is changed.

So I had a little thought: what if there was an option to add markdown syntax to the text file for formatting that would otherwise be lost? So like in the sync with external files window, an option that says markdown or basic markdown, and then allows the user to pick the file extension. So in Scrivener I would see “my italic and bold text”, and then in the markdown-style text file I would see “my _italic_ and **bold** text” which when then synced back into Scrivener would go back to “my italic and bold text” of course.

I have no idea how difficult something like that would be to program, so I don’t know if it would be worth it in the long run? Just a little thought I had for a way to edit externally synced files in the mobile dropbox app without losing said formating. Though I personally would prefer an android app like the iOS app over the idea I just described, so if it would take time & resources away from that (if such a thing is in the works, also I’m also fine if Scrivener doesn’t come to android) then I would definitely say this idea is not worth it. So it might be pointless for me to post this, but I like sharing ideas.

Speaking purely from the standpoint of the technical, I think it wouldn’t actually be that hard as a lot of code for it already exists. Here’s an experiment for you:

  1. Go into File/Compile... and from the Compile for dropdown at the top, pick “MultiMarkdown”.
  2. In the general options tab, tick the Convert rich text to MultiMarkdown setting, and give that a quick test compile.

So you see, it handles quite a bit! But you may also notice it loses a lot as well. Anything that isn’t styled in a way that can be made to “make sense” to Markdown will be lost. Font size changes, highlights, colours, revision markings, indents, that sort of stuff. A lot of that boils down to the fundamental incompatibility between a strictly semantic and willfully simple markup system like Markdown, and something with a billion and one different combinations of settings that all essentially mean nothing except what we as humans perceive of them (big bold text? must be a heading!), like RTF. So one can train the compiler and their source material to a point of being a very effective Markdown generator—but it’s often not that way on its own.

And that’s where it perhaps gets to be a little too complicated for file sync. We’re talking style recognition, prefix/suffix settings to inject custom markup around text—and that’s just to produce it. Scrivener doesn’t have a clue what Markdown is in terms of import. The best it could do is have MMD create an HTML file and then crudely convert that to RTF, which would in essence blow away all of your formatting anyway. (I.e. the best way to import from Markdown is to use Pandoc to create DOCX files and import those.)

I think ultimately that conundrum is going to be at the heart of the any attempts to make a round trip Markdown workflow that somehow collaborates perfectly with a word processor engine and its billion and one complexity.

So to return to the start, while it may be technically easy, at a more human level of what we would expect and want—I think it would be a struggle to get this working in a way that would actually solve the “problem”.

Just a little thought I had for a way to edit externally synced files in the mobile dropbox app without losing said formating.

My solution by the way is to just write using Markdown. As you can see from the demonstration above, conversion from RTF is in fact an optional setting, and Scrivener on the whole has a lot of capacity for handling that way of writing as a native platform for it. You can get word processing files out of it, web stuff, even ebook and other formats if you install an additional converter. While Markdown is very simple to write with, it has a lot of depth to it as well, and particularly when coupled with a powerful tool like Scrivener. Our PDF documentation is produced using that approach, in fact, and you would not be able to do the majority of the formatting you see in that in Scrivener otherwise.

It’s not for everyone, sure, but I love having a consistent writing “interface” no matter what software or device I’m sitting at, and I love never losing a single gram of meaning when copying a file from one system to another. RTF? Everything goes out the window, even if you can find an RTF editor everywhere you go, there is no guarantee it will know what a footnote is, or an embedded image, what bullets should act like, or how to load your fonts correctly, etc.

1 Like

Well that just sounds like an f-ing nightmare. In my limited experience with programming, writing to even plain text files was the devil. I didn’t know if there was some way to I guess make Scrivener aware of some parts of markdown? My thinking was more just directly inserting the formating the markdown syntax stands for as actual formating in the RTF, though admittedly I don’t actually know how one programs around a RTF or how it works under the hood. I know some html & css, but not RTF. So if you say it just don’t work that way, I entirely trust you and have no further questions on that front.

It’s been a while since I looked into how Scrivener & markdown are doing. Last I checked it was not so great, but sounds like maybe this has changed. Scriv 3 has changed a lot for the better. Yes, not losing intention when copying is certainly important; sort of the main purpose of markdown, at least to my knowledge? Certainly something I like about it.

Thank you for taking the time to listen & the detailed reply :slight_smile:

1 Like

For it to do that it would need a full Markdown parser, which isn’t a trivial undertaking. That’s why the more expedient approach would be to have an actual parser handle that part of it and produce some intermediary format—and without installing additional tools, that means HTML with MultiMarkdown.

Intermediary formats can be quite good, though. The Pandoc/DOCX combination I mentioned is fully styled, and if you set up your project’s stylesheet to match the naming conventions it uses, you can get a very decent import. That’s where it breaks down again for file sync though, as Pandoc is a separate install, and having to conform your project’s stylesheet would be quite a tutorial in and of itself. I don’t know if there would be a simple and easy way to accomplish it otherwise. How could Scrivener know that “Block Text” is really supposed to mean “Block Quote” (or whatever you call it) unless you tell it somehow. And without that, how does it know what it should look like? That’s where we end up back at the start: with the most efficient approach being HTML where <blockquote> can be rendered in a recognisable fashion by an RTF converter. It won’t look anything like your “Block Quote”, but at least it’s something.

If you want to poke around it a bit, I’d suggest the introductory section in the user manual, of Chapter 21. You can probably skip down to §21.4 where it goes into the different approaches one can take. Though, for optimal file sync usage and maximum “copy and paste” compatibility, the “purist approach” will always be best. I would say the software really starts to shine with the described hybrid approach though. For myself, I start purist and only start adopting hybrid techniques if I need them in that particular project. I like having ultimate compatibility, but if I want lots of footnotes without the headache, I’ll sacrifice file sync and other approaches for that—or maybe stick to a phased workflow, where initial writing is pure Markdown, and once things get to a certain point I stop syncing them or editing in other tools, and start refining the document to a higher level of production than Markdown alone can achieve.

1 Like

Seems like the path of least resistance here would be using an app that does what you want. Why live inside the Dropbox app of all things? As you said at the outset, if there was a Scrivener app for Android, you’d use it. I don’t have an Android device, but surely there is some extant app aimed at working with text/rtf files that can edit your synced files non-destructively (and access your dropbox files directly, so there is no hoop jumping).

I mean, I know part of the interest of your post was the idea of the thing, but in practical terms it seems to me using a diff app for your mobile editing environment must be the way to go.

I appreciate you outside the (drop)box thinking; however, android is a bit lacking when it comes to apps that can edit RTF, even for files outside of dropbox. Especially free apps, or at least apps that don’t require a subscription. Word on android can’t do it without paying monthly, and google docs make a mess of rtf files (it converts them to gdoc upon opening them, and messes up stuff inside the file).

I also have an ipad, and I’ve just about concluded that Scriv iOS might be the only option that fits what I want. I’m very curious by nature, and wanted to know about any other possible ways to approach this. That is, if they exist. And they may not, the iOS app was created for a reason after all.

Still, thank you for your thoughts :slight_smile: I do wish it were the case that there were other rtf editing apps that could fit the bill.

1 Like