I’m trying to banish some stray carriage returns from my complied .docx. I suspect they are being introduced during the compile process, between paragraphs— even those in the same section of the Draft (i.e. in the same document or text fragment).
Could anyone lend a hand? I’m getting a bit annoyed at having to find-replace after each compile. Please find screenshots of the Scrivener editor, compile formatting editor, and Word document attached.
Some of my settings:
I’m compiling to .docx from a modified version of the Manuscript (Times) format. I have assigned a single section layout (“Section Text”) and single section type (“Section”).
In the Section Layout editor, “Section Text” is set to export only text. “Override text and notes formatting” is checked. There is nothing in the Prefix and Suffix rich text fields.
In the Separators editor, I have selected custom default separators, with nothing in either box. Likewise in the Section Text separators— custom, but nothing. Nothing in the blank line separator, “Ignore blank lines using styles” is checked.
None of the Styles has a prefix or suffix, or paragraph prefix or suffix.
I’ve checked over the settings I can figure out to change, without results. Any hints?
Do you see the same error if you compile to RTF or PDF?
Possible that you have used a markdown-based compile at some point and created a replacement to convert one paragraph return to two? If yes, is that replacement still active?
Possible to share a sample project with some Lorem Ipsum text showing the problem?
@Login— Sharp eye. There was a checked Replacement, when I toggle it off, the problem resolves. Sure enough, it replaced 1 carriage return with 2 carriage returns. (Curiously, the text field didn’t display these invisibles— seems like that would be a worthy feature.)
I think the issue comes down to that text box being only for plain text, not formatted rich text. The ability to show invisible codes apparently isn’t built into the Mac code building blocks, and so would probably require re-inventing the “plain text entry box” used throughout Scrivener. I’m guessing it’s a monumental effort for a nice-to-have enhancement.
If you check the REGEX checkbox, you can use (\n) in the Replace column, and in the With column, you add $1$1, which will make what it’s doing visible, if a bit obscure.
What that does is finds new lines (end of paragraph characters). That’s the \n. The parenthesis in the search field tell Scrivener (the Regular expressions code within it, to be precise) to store the found value in a variable: $1. Then you replace the found value twice by entering the variable twice in the With field.
It appears that the implementation of regular expressions does not include the interpretation of all special regex sequences in the replacement fields. Probably a bug in the programming tools for Mac, as it appears that the tab character sequence \t will work as a replacement value.
So if you want such things to be visible (if you want that line in your custom compile setup at all), you can make it so.
