[LH3077] Empty paragraph sometimes displays with wrong line height

Versions affected: At least 32-bit Windows,, and

To reproduce:
Open a new project.
Create 3 short paragraphs (1 word in each is fine).
Select all, and set all to 18 point type
Select 2nd paragraph, including the terminating paragraph mark, and set to 9 point type. This paragraph displays much smaller than the preceeding & following paragraphs, and the preceeding and following paragraphs move proportionately closer to each other.
Select the text of the 2nd paragraph (NOT including the tgerminating paragraph mark), and delete it.

What I expect to happen:
The text of the 2nd paragraph should disappear, but the 1st and 3rd paragraphs should remain in position.

What actually happens:
The text of the 2nd paragraph disappears (as expected), but the 3rd paragraph moves down, as though I had inserted 18 point text in the 2nd paragraph rather than deleting 9-point type. This should not happen, as the line height of the 2nd paragraph should be determined solely from the 2nd paragraph.

To get the 3rd paragraph to move back to where it belongs, I have to select the paragraph mark terminating the 1st paragraph, and set it also to 9 point.

It’s a bit easier to follow what’s happening if I first select “View”; “Text editing”, “Show invisibles” (so the terminating paragraph markers are visible and show the size to which they’re set) but this is not necessary to reproduce the bug.

I tried to replicate this on the Mac and couldn’t, so either it’s a feature specific to the Qt text engine and how it assembles RTF, or I messed up the replication steps.

JohnL is right for the Windows version. Scrivener behaves differently from what one would expect by the experience with standard word processors. E.g. in Word, OpenOffice or LibreOffice, it suffices to select the text of a paragraph (not necessary to select the paragraph mark as well ) and then e.g. apply a new font size. This will immediately apply the new text size to the paragraph mark also and thus also adjusts the line height. Scrivener however behaves differently and this yields in the results JohnL describes.

If, as JohnL describes, you also format the paragraph mark in Scrivener, then the result looks temporarily like in normal word processors. But when you delete the last character of this paragraph’s text, then the remaining paragraph mark immediately takes on the formatting of the previous paragraph. It is as if Scrivener stores the formatting of a paragraph in the invisible space between the paragraph mark of the preceding paragraph and the first character of the current paragraph. Difficult to describe but the screenshots should help to clarify.

Thanks, this is filed!