Convert bold and italic when compiling

I’m using Scrivener to produce a PDF file via LaTeX. Inside Scrivener I’m working almost always with a rich-text formating (with bold and italics).
I know I can use the function Format -> Convert -> Bold and Italics to MMD syntax. But I’d like to know if there is a way to do that while compiling with MMD -> LaTeX (.tex) option.



I don’t think there is.

The convert option does its best, but is not fool-proof and the result needs to be checked before compiling. The problem is that the original rich text bold and italic codes may not fall exactly at the start and ends of words, so what may look like:

may actually be (using fake tags):

which would convert in MMD to:

That wouldn’t work on compile, and would have to be adjusted to:

in order to work.

But the same could be said for “Preserve Formatting” regions, and yet Scrivener does in fact support converting these to MMD, despite the risk of unintended consequences. I don’t see why bold and italic should be any different, and the lack of this support often means having to resort to workarounds which introduce greater risks. Include a scary warning if needed, but please give us the option to perform this very common conversion at compile time without making us modify our source file, if we are willing to cope with the results.

Is it that Scrivener converts ‘preserve formatting’ settings on the way to MMD compile, or that it just ignores them along with any other rtf formatting?

Speaking personally (and with no affiliation to Scrivener other than hanging round on these forums), I would rather live with the certainty of knowing the only formatting I will get on an MMD compile will be the MMD formatting I have put in.

That’s my view, but there is a wish list forum for making this sort of suggestion.

But preserve formatting shows you the precise beginning and ending of the formatting range, since it is a blue box and not merely an alteration of the visible font characteristics. I don’t see how it is comparable, when the discussion is about how italics or bold can accidentally be applied to whitespace, breaking Markdown conversion.

It has a dual mode of operation: when used in a paragraph containing non-preserved text, the preserved range is wrapped with backticks, and when the entire paragraph is within a preserve range, the line has spaces added to the front to turn it into a code block.

That’s my view as well. I highly value the fact that the formatting tools are entirely editorial with the MMD workflow—but I suppose I can empathise with the opposing point of view, in the same way that I can sort of see the appeal of WYSIWYG.

But we already have this feature request in the list, as it has been posted multiple times over the years—no need to make a new one. :slight_smile:

That’s not (entirely) true; “Find by Formatting” will highlight where the italicized or bolded region begins and ends, allowing you to check for errors. (Works especially well with “show invisibles” turned on.) Yes, you have to know to do this, but that’s true with “Preserve Formatting” too: nothing warns you if your formatting-preserved region starts or ends with a space that this might cause any problem at all, until you export to MMD and find a mess. Then, if you’ve got a dozen of them sprinkled throughout a 200 page novel, you have no choice but to visit each one manually and inspect it. For which task you will, again, probably use “Find by Formatting”, and benefit from the same highlighting assistance that you would get for italicized and bolded text. So, in terms of actual workflow, the two use cases are not that much different, and a simple checkbox just to give the user the choice to have it available in the bold/italic case would be HUGE. Even if it were only available for MMD-to-LaTeX output, it would be a help; presumably if one is going that route at all, one is likely expert enough to understand the implications of turning it on.

Well now, it’s all that faff and palaver that makes me decide if I am going to start in MMD and code my bold and italics (for a project which is going to latex) or use WYSIWYG bold and italic if it’s going to end up in word or a PDF. And if I want to take my MMD’d text to word there is a compile option which will convert the single and double asterisks to bold and italic.

But that’s just me, adjusting my puny workflow to the tyranny of what works now. (I’m not much of a social revolutionary either.) Your workflow rests on your reasoning.

And that is in fact all I’m looking for, but in the opposite direction, so I can keep my document in WYSIWYG and use LaTeX just for typesetting. It doesn’t feel like I’m asking for the moon here, or being any kind of revolutionary. I know it means I need to be careful about where I start and end my bold and italic regions. I will be careful, I promise.

It just seems kind of silly that to get that in Scrivener, I have to go through this dance each time where I select my manuscript, do “Convert Bold and Italic to MultiMarkDown Syntax”, compile, and then remember to undo the conversion so my document stays in WYSIWYG. Sure, in the scheme of things it’s not that major an inconvenience, but geez.

As noted above: “…we already have this feature request in the list, as it has been posted multiple times over the years…”.

Seriously? Years??

Well it has almost been another year. Is there any chance that this option will be around soon?

Yes, seriously, but maybe you didn’t realise that when I said that, I also meant that for years the answer to this feature request has been a resounding, “no”. As I mentioned before, this whole system was included in Scrivener from the very start specifically for people that do not like WYSIWYG, at all, from premise to practice—to give these people a purely semantic alternative approach to writing. The fact that this system did LaTeX was just a pleasantly surprising bonus, back in 2006. So the concept of using dials and sliders and buttons and fonts to use… Markdown—a notion that still baffles me to this day—was always off the table.

To be pedantic, the reason it’s taking a while is because “this option”, as a singular thing, didn’t appeal. The idea ended up being folded into a much larger expansion of the concept, which in turn has been folded into a much larger overhaul of the entire compile system—we’re talking a least seven or eight months of design and development all told, a massive job from top to bottom. And for this facet of it specifically, we decided that if we’re going to take this route, there is no sense in just sticking in a basic wrap-my-italics-in-stars checkbox that doesn’t even work right under normal misuse of rich text controls. It’s going to be a whole lot more, and it will in my opinion appeal to both types of writers and many in between. All of this means time, and it means a lot of development, design and testing—which is incidentally coming along very well! :slight_smile: Thanks for asking, and stay tuned.