Oh, so you’re saying you use the option to convert Markdown in titles in the compiler? As I recall that does only look for asterisks and underscores and converts them—it is not a full Markdown parsing engine, much less a MultiMarkdown/Pandoc level engine (like you would need to do any of the above). These conversion engines are development efforts that two dedicated individuals (and in the case of Pandoc, countless volunteers) have spent much of their time on over many years, not something we can do just to make the title field better. Hopefully that is understandable.
If you want Markdown in titles in other words, use Markdown not rich text and a basic conversion option we provide for simple inline formatting.
I would just like to do the same because some long titles are cut randomly, so I end up with a “A” at the end of a line, which looks wrong.
Well, for ebooks it’s worth knowing there is no way to know where the line will cut, so you should not ever try to force the issue. There is obviously going to be a huge difference between someone reading a book on an iPad Pro and an iPhone, or a Kindle, and then many font size choices and font families that individual readers may set in their preferences, that changes where word wrapping happens, if it happens at all.
In other words you have to be more content with awkwardness in ebooks. The best you can do is insert non-break spaces here and there to help hint to the ebook reader.
So would any of these work, and which one, otherwise please could you add it as a feature request?
I don’t know how we could do anything different here. I don’t think there is a good solution for this with how Scrivener works. While I suppose you could insert a line break character into the binder title (at the expensive of awkwardness in the binder) for PDF, that might mess up ebooks, and other things as well. I haven’t tested it.
You mention Scrivener does superb work for PDF—well, I don’t entirely agree with you on that point, and this is one reason why. It’s not very good for galley proofing PDFs and fixing local awkwardness. That kind of thing is best done in page layout specific to that edition being produced rather than as part of an engine that produces multiple file types. That is why I would never use Scrivener as a publishing tool. I understand some are fine with it, but you have to lower the bar when you do, and accept that it won’t be quite as good as a polished print work that has been fine-tuned in a page layout program.
Using Scrivener as a Markdown-based writing tool on the other hand does give one more options, like the above demonstrates. It is a better approach for direct publishing out of Scrivener, though it does come with its own learning curve. When I say I wouldn’t use Scrivener for publishing, I’m speaking more of its straight-to-PDF output from rich text. Obviously I wouldn’t say that in a universal sense as I use it to publish the user manuals—but there I am doing something more akin to page layout after compiling. So even though I can orchestrate layout-level overrides from within Scrivener, it is better thought of as delegation than direct formatting.