I upgraded from version 1 to 3 today. I can’t figure out how to remove the hash signs between paragraphs. The advice given in 2018 doesn’t match with what I see on my screen. Please help!
Sounds to me like you have your entire manuscript double-spaced manually. Since an empty line between a sequence of paragraphs is generally considered to be a scene break, Scrivener’s default settings assume that if you leave an empty line, you want a scene break. If you use a compile format (like Manuscript) where the standard for denoting a scene break is a hash, then you get a hash between each paragraph.
So how you fix that is up to you. Generally the best answer is to write paragraphs in sequence with one another, as that is the standard style for using word processor writing environments. One could also switch to a different compile format that doesn’t denote scenes in this fashion, though. Or modify the manuscript format to not denote scenes with hashes, etc.
Meanwhile, here is a list of previous discussions on the matter:
1 Like
Thank you Amber, that’s really helpful. I was transferring work from another document which is double spaced. I’ve been experimenting with other compile methods and found that Word Doc doesn’t include the hash sign. You’ve con firmed what I was beginning to suspect.
Yeah, it’s just a matter of how the Format is set up. If you tried “Modern” for example, you’ll find it inserts a decorative glyph instead of a hash. Some will just leave it alone as an empty space, like the Paperback formats.
There are two ingredients that go into it, and to see how it is set up, try this:
- Double-click on the Format you’re using in the left sidebar (I’ll use Manuscript-Times as an example), to edit it.
- This window is where all aspects of what make a format tick are set up. We want the Separators pane, from the list on the left.
- Each different style for printing text, what we call Layouts, can have different separators. In most cases the one that prints regular text is called “Section Text”, so select that from the list in the middle.
Now from here you should be able to see exactly why it’s doing things the way it is. There is a Blank line separator setting that converts blank lines to what you type in here. These settings will also insert hashes between items in the binder that use this particular layout. That way one could organise each scene or major section into a new file.
So that blank line separator is what you’d want to edit, if you otherwise need a typical TNR 12pt style manuscript.
I ran a compile on one of my projects this morning. I had chosen to compile for PDF, and in the proof copy format. I wrote this story with each chapter as it’s own file, and the section type is set to chapter.
Upon compile, I ended up with # # # separators between paragraphs. I can’t figure out where they are coming from.
Any Ideas?
It’s probably an issue of the separator for blank lines. Here it is for titled sections in that format:
in formatting novel, sections are begun with a pound sign (#. how to get rid of them
The compile format you are using is set to insert these. If you don’t want that, you can (duplicate and) edit the compile format ( for example, double-click on your chosen compile format in the compile dialog). There is a section in the resulting compile settings dialog which determines what tweeners to insert and where.
Refer to the post above which contains a few links to various checklists and explanations for what you are seeing. While the main discussion here is about paragraph breaks causing hash marks, the answers you are looking for all stem from the same capabilities and features.
1 Like
thanks. very attentive.
Double-spaced means the space between lines is doubled. It doesn’t mean extra space between paragraphs. If you want extra space between paragraphs, blank lines are not the way to do it. Here’s a video:
13 posts were merged into an existing topic: Compile to .docx without separators or blank lines auto-inserted between paragraphs
The only one I’m actually using is “Titled Section”.
Well, good.
Fix only this one layout and compile.
Check the resulting docx, make sure everything is fine.
If not, spot which other layout or style is at fault.
Btw, the thread is back to where it was earlier moved from.
Find it and rather post/reply there if need be.
Unfortunately. No luck. Still seeing extra lines inserted between every paragraph.
I want to chunk my paragraphs arbitrarily into sections, inserting nothing whatsoever between sections and manually inserting hash marks to delimit scenes . How can I do this in 3.1.4.0 of Scrivener for Windows? I read that I could edit the separator in the Manuscript template, but how would I get to that?
@onewnan, your answer is indeed in the discussion upthread, but to distill: you want to (duplicate and) edit the compile format you are using to remove the hash mark which is currently set to be the Separator between sections of that section type being assigned to your body text (“Text Section”, as it might be).
Other posters have explained how, but my question is why do you want to do this?
Scrivener can create chunks as large or small as you like, from entire chapters down to individual paragraphs or sentences, and will let you split, merge, and rearrange them as much as you like.
Once you know – even tentatively – where the scenes are, though, why not use Scrivener’s Binder hierarchy to capture that structure for you? That is, instead of manually sticking a hash mark between paragraph A and paragraph B, why not put A (and predecessors) in one document, B (and successors) in another?
Generally I let the binder separate scenes, but occasionally the within a single scene I have shifts of perspective or location and use *** to designate the shift within my one unit. But agree let the compiler do the work for you.
For when I want a blank line within a scene/document (not ***, but just an empty line – simple location change, time lapse etc) but don’t want to risk messing it up, accidentally editing it out to then forget about it, I have set myself a substitution.
▼▼▼ is hard to miss in a printout as well as on screen. It could hardly be more obvious that an empty line is intended there.
Later, using the substitutions of my compile formats, I replace it back with whatever it is I need in the final output.
“Blank lines” with a non-break space in them when compiling to epub, for example.