Okay, got a new issue now, in the same vein as the last one.
So, Scrivener refuses to parse italicized/emphasized text when compiling into a Markdown format. Which means I have to resort to using a Style. Which is, okay, annoying, but no big deal.
Trouble is that unless I specifically put in asterisks in the prefix and suffix fields for the style in the Compiler, it will not put in the markdown code for italicized/emphasized text. Okay, annoying, but still workable…
But then the Compiled result comes out. And this happens regardless of the line spacing settings.
It seems to remove line breaks so there is no empty lines between paragraphs where emphasized/italicized text is used. Which means I need to go and manually add them in after compiling, or else when I convert via PanWriter/Pandoc to MediWiki Markup format, they turn into walls of text.
Is this a known bug, or is there something very esoteric that I’m missing?
I don’t believe that is a bug that has been spotted yet, as it seems to be very specific and only occur using an uncommon combination of settings (plain-text paragraph formatting application + whitespace transformation + character styles + style prefix/suffix values).
Thanks for the report, we’ll get it written up.
By the way, if you aren’t actually writing using markup, but just want the markup quality in your output, have you considered using the Convert rich text to MultiMarkdown setting in the compiler? That setting does assume you know nothing about it, and aren’t using any markup in your editor (an assumption that can be overridden, but you won’t be getting away from styles in order to do so). Styles are in the end, how we tell software what we mean.
It’s entirely optional to be clear. I don’t use styles for something as simple as generating Markdown syntax for the most part. I just type that stuff in because I’d rather see it and I strongly feel there are major advantages to doing so. Being able to copy a chunk of text out of Scrivener and into Sublime Text with zero loss of its internal structure, for example, is just one such advantage. If we felt that this was an important way of using the software, we’d probably build a lot more prefab stuff around it, rather than just suggesting a few hints here and there for how you can do that.
To reiterate what was said in the other thread: the software’s default assumption is that you’ll be using it as a platform for authoring Markdown content. Even the conversion option I mentioned is rather limited, and will still often require you to announce what you mean with styles.
Thanks for the tip about the Rich Text to MultiMarkdown option. For some reason, when I’d seen that option before, my brain was parsing “Rich Text” as RTF file type. So far the only hiccup it’s throwing me is for custom separators. I’ll let you know when I know more, but so far it’s putting a backslash at the first character of the separator. Weird.
Part of the issue for me is that I have quite a bit of content already written up, so it would be an even bigger time-sink to have to go through everything and manually insert markdown code. So it’s not like I’m starting off fresh and can just code this stuff on the fly.
And most of the strange and unusual settings combinations are mostly me trying to guess at things because, unfortunately, I am very much ADHD and having to sit through an entire tutorial just to learn about a single feature that does something small-but-critical isn’t easy for me to do.
At the very least, my inexperience has led you folks to some very interesting/unusual bugs to suss out.
Having to use MediaWiki Markup honestly isn’t by choice for me. I’m part of a collaborative writing project where my collaborators are programmers by hobby or trade, and so they think nothing at all of writing up entire stories purely in MediaWiki format. And thus, they absolutely insist on using the blasted thing.
So if I could effectively go from Rich Text in Scrivener to Markdown in PanWriter/Pandoc, and then export from there into MediaWiki, then it would be an ideal solution for me.
Addendum RE: Custom Separators + Rich Text to Markdown
The separator I was using before was four hyphens followed by a linebreak (because without the line break, it winds up getting parsed as a table in the Markdown → MediaWiki conversion). But then I remembered Basic Pandoc allows for other ways to indicate a horizontal rule. Using four asterisks with spaces in between each asterisk seems to work just fine.
And thanks for that! These optional, lesser traveled areas of the software don’t get as much testing from one release to the next. The other one (with paragraph spacing not saving) in fact was fixed ages ago, but for some reason the fix got lost.
