I have heard (sorry, no refs to hand) that unless preventative steps are taken, em-dashes used to indicate a break, like this
“You did once, you—”
can become detached as a result of compilation, leading to this, at the end of a line:
“You did once, you
—”
Question: because producing a good test case is a bit tricky and I am a tyro at compilation, I’d just like to ask, before potentially wasting time: can I use compilation replacements to substitute [word-joiner]+em-dash+close double quotes for all instances of em-dash+close double quotes? Any special instructions?
Thanks. Yes that sentence is short, but there could be text in front of it, pushing it to the end of the line.
Yes, I do see the line spacing change in Scrivener when the word joiner is used – even though I am using Calibri. Twice - on insertion of the joiner and if the cursor is moved into the joined words.
No. My substitutions are setup as follows:
Two dashes are replaced by an en-dash.
Three dashes are replaced by an em-dash. (Feature in the menu unticked)
—” created by four dashes. Since on Scrivener for Windows the quotes are opening quotes. So that takes care of that.
I’ve never heard of a quad, but I’ll get there—after all, life is for learning.
That’s pretty much what I do, except I also want a word joiner in the replacement and I would like to know whether that can be done in the compile replacements.
FYI (I had to check myself): quadrat (seems to be the generic; I thought it was the widest)
noun (printing) a piece of type-metal less high than the letters, used in spacing between words and filling out blank lines (commonly called a quad), distinguished as en, em, two-em, and three-em;
Thanks, I read about quad and its spaces, and immediately wondered is it something that’s still relevant today.
I’d say that what doesn’t work in Substitutions won’t work in Replacements under Compile.
For example: In the following extract, I put in a non-break space (Unicode 00A0) after the word ‘tongue’ before the em-dash. If I press the spacebar once more everything from the word tongue onwards will break to the next line. Substitutions auto-reverts non-break space to a normal space - see the result after the word ‘let’.
L&L have been particularly quiet on this topic. It may be that they regard these elements as things to be sorted out by third party apps.
Perhaps someone in the know from Microsoft can explain how Word and the like has no challenges with these elements.
Which elements? Word Joiners not having a problem with the majority of fonts like Scrivener for Windows has and universal support for non-breaking space.
Then there’s the question for us to understand, like what are the rules around the type of "punctuation we’re looking at? Is a space required after the last word before the em-dash or not? Is there a space required after the em-dash before closing the inverted commas (quote) or not? Is an em-dash and closing quote allowed to be orphaned to the next line? I’ve seen examples of differences in published works. I’ve also watched some videos on “these are the actual rules”, much of which sounded like a load of codswallop.
@Kevitec57 : L&L have been particularly quiet on this topic. It may be that they regard these elements as things to be sorted out by third party apps.
Well that was my first thought, when I read this thread. If Word is formatting these in a fashion that follows most style guides, or any other word processing system you may use, then why the need to force anything from Scrivener’s side? I may be misunderstanding the use case.
But as you note, most of these “rules” are conventions. Some may be more widespread than others, but almost all of them have regional variations, never mind across languages.
As for Replacements, has anyone actually tried it? It’s quite simple to do, and seems to work fine at least with ODT. I inserted a word joiner followed by an em-dash, selected both characters and then copied and pasted them into the Replacements table, with a simple single-character em-dash as the thing to be replaced.
The resulting .odt file has the special character in it, and it functions as expected when pushed to the end of the line.
Thanks. I didn’t run a test but stopped at the Replacement menu.
I have it working now, but one thing to note. Copying a ‘non-break space’ and all the rest from the Scrivener for Windows editor and pasting it as a Replacement converts the non-break space to a normal space character. Running a compile still renders a normal space character in Word, whether DOCX or ODT.
However, copying a non-break space and all the rest from Word and pasting that into the Replacement field brings along the correct formatting of the non-break space (its symbol similar to a percentage symbol shows up correctly), and it compiles with the required behaviour.
Using Replacements instead of Substitutions will sort out my other thread on non-breaking hyphened names I wrote about elsewhere and will no longer interfere with the line spacing of non- supported fonts in the Scrivener for Windows editor.
Replacements seem to me a cleaner solution anyway, as littering the source text with such specific typography commands feels like bad practice to me (even if you’d mostly always want it?). It’s the sort of thing where you could insert them if needed for a particular Format to a file type that doesn’t handle this problem natively, but not force the matter to file types that work right when opened in software that handles this problem dynamically (like Word).
As for non-breaking spaces, I wasn’t looking into that, just the original query. I’m aware of issues with that character, and a few others, in various (but not all) search and replace functions. We do have tickets on them already.
)
