Unexpected document change after reopen

I’ve been dealing with this for months and it seemed to be a random behavior, but finally I’ve been able to reproduce it at will, so I post it now. I’m using Scrivener for Mac (NaNo) on Mavericks.

Let’s say I have three documents (1-3). The second one contains only a single cell table. No text above, no text below. In Scrivenings mode the whole pack looks as on the following picture. I have Show invisibles on for clarity.

Then I close the project (without modifying any of the documents) but, after reopening, a newline —that was not there before— appears on the last line of the table (notice the new pilcrow character).

The problem gets critical when I compile the manuscript, since those extra lines appear on every table that is located at the end of a document, as seen below:

compile output.png

How can I prevent Scrivener to add that extra newline inside the table?

It seems to be in part a text engine behaviour (I’m not sure if it is a bug, per se), and perhaps an interaction with how Scrivenings uses dividers between sections. If you try your test in a single document in Scrivener, or even just using TextEdit, you’ll find that upon closing and reopening the project/RTF file, you’ll get an empty line below the table. It’s impossible to have a table at the very end of a document, from what I can see. Something about Scrivenings causes that behaviour to modify so that the empty line ends up in the cell instead of after it, but given that the underlying behaviour is within the text engine, it may be unavoidable. Hmm.

Here’s why I’m not sure if it is a bug: I simply cannot make an RTF file with Microsoft Word, Nisus Writer Pro nor LibreOffice that does have a table at the end of the file. In fact in those three word processors, the text editing interface outright refuses to even let you delete it, unlike the Mac text engine. So perhaps it is some issue with RTF in general? Well, I’ll see what Keith thinks—obviously the current behaviour in Scrivener doesn’t match what I see in Word and TextEdit, so maybe at least that part can be fixed, but I’m afraid having a table at literal the end of an RTF file looks to be impossible.

Here’s another interesting thing I noticed: view that document after reopening it, just the document all by itself. No carriage return in the table. :slight_smile: It’s after the table, as in all other word processing software. It’s only when Scrivener is inserting separators after the table, such as in Scrivenings mode and Compile, when the issue with the pilcrow being in the cell occurs. And of course, once Compile does it, it becomes permanent.

I’m getting it a little different, maybe based on how the table is made? If I create a document, not in Scrivenings, and give it nothing but a table by deleting the extra line after it, then on reopening the pilcrow is inside the table. The caret appears on the next line, outside the table, but as soon as I begin typing the table expands to include the new line.

For extra fun, you can’t get around it by adding an extra line after the title that you delete via compile replacements. Compile adds the extra blank line into the end of the table anyway. :neutral_face:

That’s true, there is some weird stuff going on when the table is forced to the end of the file using the Mac text engine. I get weird redraw errors, and the issue you note where typing on the empty line then causes the table to expand to include that line. Some awful looking stuff can then happen, where if you press return after doing that and type another letter, then backspace, the cursor jumps around illogically. I think clearly RTF has trouble with this scenario and other text engines have dodged it by just not allowing it to ever happen that is my guess anyway, I can’t think of any other reason to force a blank line and refuse to delete it—but Apple just lets it happen, and nonsense breaks out. :mrgreen:

You mean it doesn’t just work?! :open_mouth:

I tried the same exercise on the Windows version and it gets weirder. Upon creation, the table shows a pilcrow as the first character inside the table (before anything I typed) and then another one at the end (after typing the cell contents).

Then I close the project, reopen it again and there’s another pilcrow after the table, outside (3 in total). :unamused:

So, what should I do? In order to maintain compatibility of the files across Mac and Windows, as well as to avoid those extra pilcrows appearing on my tables, would the suggested strategy be just not to ever user a table at the end of a text document?

In Scrivener, delete the pilcrow in the table:

[attachment=0]inscriv.png[/attachment]

Compile (this example is compiled to Word) and the layout is fine:

[attachment=1]compiledtoword.png[/attachment]

Closing and opening Scrivener causes one pilcrow to reappear in the table, but this has no subsequent impact on further compiles.

So, just delete the trailing pilcrow when first creating a table.

If you close and reopen the project and then recompile, is the resulting layout also correct, in your case?

Yes, it is. Here is a screenshot after closing Scrivener, opening it again, and recompiling to Word:

[attachment=0]recompile.png[/attachment]

The extra lines after each doc are just the separator settings used during compile. Can be turned off, of course.

Well, unfortunately the trick does not work for me :frowning:

Perhaps one of the devs will be able to explain why.

I have tried it on 3 Macs, with new projects on each Mac, and it has worked every time.