Is there an equivalent in Scrivener (or Markdown) to LaTeX’ end-of-line command (\)?
I’d like to present the following as single-spaced text:
Author
City
Date
But with single carriage returns, the result is:
Author City Date
with double carriage returns, the result is:
Author
City
Date
which is undesirable, as this should be single spaced.
What is the solution?
This is an easy one, in Markdown there are two ways to create lists of lines that are all necessary considered a part of one block (a paragraph, most commonly, but we can think of a street address as being a block):
Both
of
these
methods
work
here on the forum, too!
(Although the forum also turns adjacent lines into <p>one<br/>two</p> constructs as well, as it has to cater to people that aren’t familiar with strict Markdown rules.)
Thank you for this. I also appreciate the tip about Sigil–my ToC was turning out with some entries beginning with ### and other, same level entries without. I just did a quick test and was able to delete these in Sigil after generating the ToC in Scrivener=>Pandoc=>ePub.
It didn’t work.
I tried:
author
cityspace>
date
which yielded double spaced text.
Then I tried:
author<CR>
city<CR>
date<CR>
Same result: double-spaced text.
Then I tried:
author<CR>
city<CR>
date<CR>
Same result.
I have not tried:
author\ because I would have to add an additional at the end of the line.
It looks like the forum is escaping text within these brackets<>
Did you leave the option on that converts rich text to Markdown, in the compiler? That might make a mess of things, it’s not going to be expecting Markdown input. That might explain why you are getting spurious “###” in headings, too.
Yes. It produces an extremely detailed (3rd level) ToC. If I remove it, I get a ToC only half as long.
One of the eccentricities of this document is that the ToC is just as, if not more important than, the text. Keeping it produces both a shorter ToC and the need to plow through the document again and implement your suggestions concerning italicized text. It’s easier to remove the crosshatches in Sigil than to re-do all the italicizations and make sure that they work–there are two struck-out sentences as well that I am afraid to address. The issue with italicization–and I very much appreciate your in-depth analysis–is that in this type of legal writing, they convey semantic meaning. They are not used for emphasis–the italicized sentences carry no more weight than the non-italicized, but they are new, and this has be conveyed somehow. Emphasis is a trap: just because a sentence/paragraph/page is new doesn’t mean that it has more gravitas than an old sentence. Additionally, different regulations that implement these laws are included here, which is not the norm for statutory books which print laws discretely. How to make them stand out? One way might be to use different fonts. Ultimately I decided on italics for these as well. I have seen other legal publisher relegate these to footnotes or omit them altogether. Footnotes are troublesome in the ePub world: some readers convert them to end notes, and while clicking on them is supposed to be easy, it is often difficult to navigate back to where you left off in the text. The legal world still hasn’t figured out what to do with the loss of page numbers, this is probably the reason why ePub’s have not overtaken pdf’s: you just can’t cite to an ePub like you can to a pdf.
Hmm, that could be the case if you used a mixture of Markdown headings and styled headings, where the styled headings have been set up with Format ▸ Paragraph ▸ HTML Header Level. Those would convert to the respective number of hashes with the RTF conversion option enabled.
You can do that without that setting though:
### (with a space after).Give that a test with the RTF conversion option disabled, and see if you get a full ToC and a lack of hashes to clean out with Sigil. You might need to create various other heading level styles as well.
It’s your call of course, but it sounds to me like you are battling with a beast that has multiple different types of content, and with settings that are essentially all-or-nothing. You’re going to be stuck doing manual labour to clean things up without a lot of workarounds being applied.
So I guess overall the moral of the story is to stick with one method or another unless you plan for a more hybrid approach from the start.
At any rate, now that I know what settings you are using, the way to get a list of lines in a paragraph with this conversion setting enabled:
Format ▸ Preserve Formatting command.Consider that tool in other areas where you may have raw markup that you’re having to clean up in one form or another.
As for the rest, I think I miscommunicated a bit there, as I certainly did not mean to imply that italics = emphasis and nobody should ever use italics except for emphasis. Rather the whole point of the solution I gave was to allow for italic formatting in cases where it is appropriate and semantic to do so—without using the emphasis markup to force it, but I’ll follow up in the other thread.
The legal world still hasn’t figured out what to do with the loss of page numbers, this is probably the reason why ePub’s have not overtaken pdf’s: you just can’t cite to an ePub like you can to a pdf.
Yeah, that’s an interesting problem indeed. Amazon actually came up with a really good solution for it, using its “Location” metadata. I forget the precise details of it, but one can extract a location from any sentence (roughly), and share that location in a citation or to another reader. They could use the Kindle’s Go To function to jump straight to the reference, no matter their font settings or otherwise (naturally they would need to be using the same edition, but that has always been a natural limitation with paper page numbers as well).
Of course the problem is Amazon’s insatiable greed. With their implementing this solution into a proprietary format nobody else in the world can use, it is only useful to other Kindle users. No doubt they probably patented it and every imaginable variation as well, so nobody else can easily apply the technique to a standard and open format.
Footnotes are troublesome in the ePub world: some readers convert them to end notes, and while clicking on them is supposed to be easy, it is often difficult to navigate back to where you left off in the text.
I’ve never encountered a modern reader that doesn’t have a “back” button or shortcut/gesture somewhere, but yeah, for maximum compatibility you do need to insert a hyperlink that goes back to the footnote marker directly, as Pandoc and Scrivener do.
This reduced everything to a single line.
What did? Sorry, I don’t have enough information here to provide constructive feedback, I’m afraid. I need to know what you actually tried, and what you tried it on—I only have half of that information. Use fence code block syntax to demonstrate your text verbatim. If you don’t know what the syntax is in Markdown, position your cursor on an empty line here, and click the </> button.
I am trying here to have single spacing (like an address block) with the following information:
name
city
date
This shows up as double spaced. At the beginning of the thread, I asked:
Is there an equivalent in Scrivener (or Markdown) to LaTeX’ end-of-line command ()?
I’d like to present the following as single-spaced text:
Author
City
Date
But with single carriage returns, the result is:
Author City Date
with double carriage returns, the result is:
Author
City
Date
This is double spaced and not desirable.
I found out that <s> and </s> worked when compiling so I just tried using html:
<par> name <br>
etc.
but it didn’t work.
Nor did:
<par> name </par>
<par> city </par>
<par> date </par>
Nor did:
<par> name <br></par>
<par> city <br></par>
<par> date <br></par>
The “preserve formatting” command didn’t work:
Previously I tried:
None of these has worked.
Trying to use line height parameters removed the second and third lines of the address block.
Using
followed by the three lines, followed by </> ended up back where I started: a double-spaced address block.
As did:
This didn’t work either:
Author
city
date
(see, Tryit Editor v3.7)
So I’m at a loss as to how to single space three lines of text.
This is the text-editing setting in the editor:
I even tried
<pre>{three lines of single spaced text}</pre> but once again got double spaced upon Compile.
If I read you literally, it sounds like you tried Markdown nomenclature, and that didn’t work because you have the setting enabled to treat the source as RTF instead of Markdown. So I showed you how to apply a field around some text that is meant to be treated as Markdown, to preserve it, and you did that, but at the same time you removed the Markdown nomenclature for multiple lines? In that case, the result you got is logical: you’ve supplied three adjacent lines and then told the compiler you want them treated as Markdown, and adjacent lines in Markdown are merged into paragraphs. The point of using Preserve Formatting is that the Markdown I advised you add to the ends of the lines would stick.
This is the Compile setting:
using (default) Pandoc=>ePub.
with and without the Treat Formatting setting:
still yields a double spaced result.
I don’t know. The main factors that would make it work are in the text editor. It works fine for me. Perhaps an example would work better.
pandoc-ebook-multi_line_test.zip (131.9 KB)
I compiled using Basic Pandoc and Default Pandoc.
In both iBooks and Adobe Digital Editions 4.5, the text was double spaced.
I will try to fix in Sigil.
In Sigil you should find this HTML, which is correct:
<p>Dri srung gronk ozlint; zeuhl la, ti dri....</p>
<p>Line One<br />
Line Two<br />
Line Three</p>
<p>Re teng thung; kurnap fli rintax ti nalista gra athran epp....</p>
If an ebook reader displays that as double-spaced, it’s an issue with how it displays lines. You might have to try and override how it displays lines within paragraphs using CSS. That’s a bit of an odd choice of them to make though, as that’s not how <br/> is supposed to be rendered.
I tied Calibre, Kitabu and E-Book viewer. Same result. Sigil doesn’t reveal any html mark-up in your example:
Interesting, looks like a bug in how the Windows version saves Preserve Formatting in a way that isn’t compatible with the Mac. On the Mac, you would need to select the three lines that are currently marked individually (triple-click on “Line One” and drag down until “Line Three” is highlighted), and turn Preserve Formatting off and back on.
As for Sigil, that looks like a very old version of it? I don’t know if it has a combined preview/code editor view like that any more. It uses a side-by-side setup now. But there should be a way to toggle between code view and WYSIWYG mode somewhere, I don’t remember where though.
I found the Code view on Sigil:
So my guess is that this is limitation of the ePub format.
No, ePub is perfectly capable of storing <p>line<br/>line<br/>line</p> content, and ebook readers should display it properly. But as you can see in your screenshot, that’s not the HTML you have. I’m guessing you haven’t yet tried what I said you need to do to fix the sample, though, since the HTML in your screenshot is what you get if you don’t fix it.
This is your code:
not mine. It displays double-spaced on several ePub readers.
