Adding a new line in a title with markdown

Scrivener Scrivener for macOS
, ,
1

Hi there,

I’d like to add a new line in some long titles to control where they are cut when compiling the project to PDF.

Markdown in titles works fine withitalics for example (so the option to convert markdown to html is enabled in compile), but I can’t find a way to break a line in a title.

I tried   and
, none worked.

Any idea how to achieve this?

Thanks!

2

You can’t do this using regular Markdown syntax. You could use HTML tags.

3

Yeah, there isn’t a native Markdown break that works in headings. There is the \ on the end of the line convention, which is how you could make a casual list in one paragraph, but headings are a bit special and stuff like this is usually more the sort of thing you’d be optimising in the output itself rather than the source material. I.e. there is no semantic reason to be cutting a heading in two—or where one might say there are, it is really different things we are talking about:

  • A subtitle, which isn’t supported directly by most engines semantically and only handled visually—thus the first line of text following the heading should be marked, like [This is the subtitle]{.subtitle} in Pandoc, and the matter handled by the stylesheet.
  • A presentation choice, or something purely at the formatting level, such as “Chapter Twelve” on line one and a descriptive title on line two. This has nothing to do with semantics though and should always be purely a matter of how the stylesheet is designed.
  • And then stuff like you describe, where one is essentially galley proofing, way past the point of writing content, and is looking to optimise line-wrapping. Again while Markdown doesn’t support that kind of stuff directly, it does support it indirectly.

It depends on the output format though! First, here are the most common codes that are used to break lines within discrete elements:

File Type Break Code
HTML <br/>
LaTeX \\
DOCX <w:br />
ODT <text:line-break/>

Something we do have in our favour here, with Pandoc and MultiMarkdown, is the ability to target formats specifically, so that we can insert stuff like the above markers only when generating that kind of file—otherwise it is left out of the output. This also protects the syntax we type in from any methods it would normally use to escape it, and print it verbatim into the output.

This is done using a variation on the code span syntax:

`\\`{=latex}

Thus if we were primarily interested in LaTeX and DOCX (for proofing copies we distribute) we could chain the two of them together:

`\\`{=latex} `</w:t><w:br /><w:t>`{=openxml}

NB: in DOCX we cannot place a break inside of a text element, so we must first close the current line’s text element, break, and then start a new one for the next line.

Now you have something that will break cleanly in both file types. Of course—that’s a bit of a mess to copy and paste into your binder title. :laughing:

This is of course where Replacements come in handy. You could type in something simple and obvious like {^} into the text wherever you want a hard break, and the replacement would turn that into however much syntax you require.

Special note on HTML: being somewhat native to Markdown, it is valid to insert HTML directly into the text—thus one could type <br/> right into the binder and be done with it. Just know that doing that all by itself will mean nothing in formats that do not use HTML, and might even be visible in the output in some cases—so even then I would consider using:

`<br/>`{=html}
4

Thanks Amber,

Just to clarify, I only compile to EPUB (KDP ebook)) and PDF (KPD and INGRAM print book). I never compile to anything else as my workflow is Scrivener only for all our publishing. I only mentionRTF when someone else does, but it’s unlikely I’ll make my workflow more complex unnecessarily.

Believe it or not, Scrivener does a sterling job of outputting professionally formatted files that can be directly uploaded to these services (and since 3.3, no need to do an extra conversion for Ingram).

So I use markdown in the binder, because all my titles are in the binder. For exemple, I use italics in the binder title and it works great (at least with scrivener Mac). This is compiled as italics in the PDF for the print book, which is what I want. So I’m not sure why I couldn’t use a markdown command in the binder to achieve a new line. There is even an option in the compiler to convert markdown in titles to html, so what is preventing this from being done?

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. This is a legitimate use, because I’m talking about long-ish titles for some chapters or sections in the binder. Not subtitles (which are not handled layouts/formats as far as I know).

Hopefully there is a code I can add in the binder title to do this. I’m fine using replacements, I already do that for image formatting.

So would any of these work, and which one, otherwise please could you add it as a feature request?

Thanks!

5

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.

6

Thanks amber, I appreciate this. I would only use this for PDF output, as indeed a line break wouldn’t work with EPUB.

I guess I’ll have to find the workflow to export from Scrivener into InDesign, but the books I’m publishing look fine with the output from Scrivener, bar a few very minor issues like this. I can literally produce the same thing as my professional graphic designer produces with InDesign. Not as complex as the Scrivener Manual, of course :slight_smile:

We published the first volume with the print book in In Design and the EPUB with Scrivener, but I tried to move away from this with the next volumes because it’s annoying to have to make any changes to two different master files. I also don’t like how everything is kind of “locked” once it’s in In Design. Having the ability to make corrections and compile directly to EPUB and PDF is a real timesaver, so I’ll probably stay like this for now.

Thanks again for your help, I’ll give up on this if it’s not something that can be implemented and work as the * for italics or with replacements.

1 Like
7

Could one not still use the strategy of putting a marker ‘^’ in the title, and then include a suitable Replacement in the EPUB and PDF wings of the compile format – removing it in the case of EPUB and replacing it with a newline character in the case of PDF?

8

Thanks, worth a try. Which string would you replace the ^ with in the PDF?
[EDIT: I tried with OPTION-COMMAND-RETURN (ALT-CTRL-RETURN on PC) and it doesn’t work (the caret disappears in the PDF but there is no line feed}.]
[EDIT2: I was looking at the TOC that I had forgotten to update, not the title itself. It works GREAT! Thank you for the suggestion, that completely solves my problem]

SO for anyone looking to do this, simply use a special character (^ works for me) and replace it in the PDF compile settings with OPTION-COMMAND-RETURN (ALT-CTRL-RETURN on PC) (you won’t see it but it registers) and by nothing in the EPUB compile settings. Works a treat! Thanks again gr for the suggestion.

[EDIT3: The only limitation is that the ^ isn’t replaced in headers and footers, only in titles and text. I also corrected the keystrokes to get the line feed because I had muddled up my PC/Mac keys].

1 Like
9

Hey, glad to hear it worked.

About the lingering issue with the headers/footers. Traditionally, in typesetting, a shortened title is used in place of any awkwardly long title in headers/footers. I am not sure if Scrivener has any way to facilitate that. The way this would get handled even in inDesign is pretty out of the way and definitely manual. So, well, maybe we can’t ask for the moon.

10

No worries, I was only mentioning it. The footers are changed automatically by scrivener and the length isn’t an issue. I can live with this. Thanks again for your help.