Compile: Text centering after a comment and inserting a hash-tag

• I’m in 3.0.3, on a MacBook Pro funning macOS High Sierra 10.13.6, and Word for Mac 16.16.2.
• I’m exporting to a custom format, saved from Manuscript (Courier). I had to create a custom format as I can’t turn off “Conversation italics to underlines” without creating a custom format.
• Upon export, some comments are followed by a return, a hash-tag on a new line, then the remaining text on the line after the hash-tag. When this happens, all remaining text of the scene is centered.
• This does not happen with all comments.
• When there is a comment at the end of a sentence, your software appears to put the return, the hash-tag on its own line, then the period on its own line, then the remaining content of the scene (the hash-tag, the period and the remaining content are centered).
• My manuscript is 130,000 words — I can’t go in and remove every comment, which makes my book dead in the water until I can figure out how to fix this.

I get this:

When I compile this:

I am also unable to remove the highlighting on this part. I’ve tried from the Format menu.

More information for you.

In the compiled MS Word version, Scrivener has converted comments to some kind of mangled hyperlink.

This in Scrivener:

Becomes this in Word

And if you click “yes,” you get this:

To explain the premise behind the hash, edit your compile format and go into the Separators pane. Under “Text Section”, which is probably what you are using for scene text, note the setting here where empty lines placed into the text editor will be converted to the standard scene break (a single hash mark for this format). So that’s what is causing the appearance of the hash.

As for the why, that does appear like it might be a bug to me. I tested two kinds of comments, one with a stray newline at the end of the comment and the other just left as a one-liner. With the comment that ends with a newline, I get the same result you do, where the newline is inserted into the main editor instead of stripped out of the comment, and this effect causes the separator behaviour to trigger. As you can see in the case where the comment terminates before the full stop, the newline is actually inserted between the punctuation and the final word. As I say that looks like something that should be fixed—but in the meanwhile I’d check these comments in the inspector and make sure they are trimmed of any whitespace. It looks to me as though trimming the comments will at least clean things up for now.

Re: weird alignment following the comment, I didn’t get anything like that in my testing, so I’m not sure what is causing that. I would select the area of text around this spot and use a Cut, then the Paste and Match Style command to make sure there is no odd formatting in the text. You can drag the comment out of the way temporarily, as Paste and Match Style will strip all formatting, including comments.

That doesn’t look like a normal highlight, it looks like the project search result highlighting feature, with the darker orange underline on it. If you clear the search from your binder sidebar it should go away.

That looks like a bug as well. The link is the original internal link used by Scrivener to select the comment. It should be removed from the compiled output since it won’t function outside of Scrivener.

For a workaround, do you need hyperlinks at all in the manuscript? If not, then check the Remove all hyperlinks option in the general compile settings tab.

I’ve replied to Scott via our support email channel (Scott, if you’re reading, please check your email) and have fixed these bugs for the next update. The first bug is triggered by the blank line replacement # affecting comments, the second by links being left in.