Whenever I compile to markdown, every time I have a passage of italics that intersects with a new line or another sort of punctuation, something’s going wrong and the italics can’t be imported properly and are left as just * signs in the document.
I think this is a scrivener export issue because I have tried importing the markdown into multiple other programs that have the same problem. Italics within a plain text passage with no punctuation or new line are fine.
I’ve attached an example of this happening, but for brevity, here is a short example: The stars in the following are present in the import.
*Italics Start here: Excepteur sint occaecat cupidatat non proident,
faucibus ex sapien vitae pellentesque sem placerat. Italics End here.*
also another example: the “leo” and the “m-dash” were in italics in the below.
Thanks! This is definitely a bug, as valid Markdown (like HTML) requires inline formatting to be terminated at the end of each line. I’ve got that filed for review.
There are workarounds, but all would require changing how you work a bit (or a lot), unfortunately:
If this project only compiles to Markdown, then you could insert an empty line between these two, and add a space, ensuring the space is not formatted with italics.
You can switch off the setting that escapes special characters, which in this particular case will allow you to use asterisks in the source itself, putting you in full control. However if you write with punctuation that could be confused with Markdown, that might cause other problems.
Or, switch off global conversion entirely, and migrate to a style-based writing method instead of raw formatting like this. For example, with styles such as “Emphasis” you can add asterisks in the Styles compile format option pane. If this is primarily or solely a Markdown output project, that’s not a bad route to take. The option you are using is a bit fly-by-wire, and limited when it comes to doing more advanced formatting—really more aimed at those only needed Markdown periodically, or to just try out the quality of the outputs without committing to it.
I don’t see the second condition happening, unless I deliberately enclose the em-dash in italics as well.
Unfortunately this is a 130k manuscript so putting in asterisk manually is not an option, and my use case is that I need to export the manuscript to over programs occasionally and the other program only supports markdown as an import, so option 3 would probably be a bit excessive too, so it seems like I’m going to have to keep manually correcting this.
I did a bit more investigating on where some of the mystery asterisks were coming from too, and found out that it’s been caused by revision colours as well, so hopefully this context can also help with solving the bug.
Weirdly it doesn’t happen with 90% of revision colour instances, just a few of them.
Example:
First draft text here; second draft text, third draft second draft, First draft text.
turns into:
First draft text here; **second draft text, **third draft **second draft, **First draft text.
I’ve generally had problems with compiling with revision colours and compiling and struggle to get rid of them so normally have to set them all to black.
While not applicable to plain-text outputs (which have no colour of course), do you mean by this that the Remove text color checkbox doesn’t strip them out sometimes? I would need more detail into how to create that condition, as simple testing doesn’t show any issues of that nature.
Do you have perhaps a better way of demonstrating this, such as a small sample project you create, using “Blank”, that shows how the text is marked, and produces this markup when converted to Markdown?
I can’t really tell what is happening here, with a translation into pure text via the forum (which itself uses Markdown, so unless you use a code block (</> button) , it might not convey everything you paste.
As with the other issue, I don’t see this happening in a simple test.
Here is a project with the sample issue and a screenshot of my compile settings.
I had to transfer some text from my original project in to get the revision colour markdown ** issues. Doing fresh revision colours didn’t cause the issue.
I think because this is a large long-lived and heavily edited document, perhaps the revision colours could have become in a weird state? I do frequently change the revision colour shades in the options.
The remove text colour checkbox doesn’t remove some of the older colours that seem to have gotten out of sync with the revision colours.
Aside, the italics over the new line issue was easily reproduceable with fresh text.
Okay, I don’t think the problem has to do with revision markings. The first thing I did was use the command to strip out all revision markings. Because you use different colours, this didn’t change anything visually for me, but I could see from the raw RTF that the command was successful. I compiled, and nothing had changed. So then I selected the text and removed all colour manually, and compiled—again there was no change.
The thing that had me perplexed is why it was signifying with bold (two asterisk) in such random places. It’s not that it is bold, it’s that there are scattered remnants of Emphasis formatting attached to various points within the paragraph, so **, where this isn’t a “start bold” markup, but italics around nothing. In the editor it is actually applied to some of the spaces between words (which is why you cannot see it).
You can see this by moving the cursor through the areas of text that have the double-asterisk, and watching the Format Bar. Hence you can clean this out by select the paragraph and using the No Style command (AltShift0).
All of this is why I love writing with Markdown. None of this invisible formatting on spaces stuff!
