Blinking Cursor height issue in editor

Hi there,

I have started using Scrivener 3. I changed the main text style for new documents and I noticed that the cursor behaves strangely. It is full height but only blinks on its lower part. The top part remains non blinking.

I also notice that when you select text, the coloured line that indicates selection appears half.

Please see attached screen capture which also shows the non blinking part of the cursor.

(I hope you can see screen capture)

Sorry, I do not know how to post the screen capture using the img tag…


ibb.co/z5H99Fr

I have exactly the same problem. If I change the format (line spacing), the cursor starts to blinking in half only. Maybe its a bug of some kind, I don’t know.

1 Like

Sounds to me like a bug in the graphics card driver and not in Scrivener. Perhaps you should try to find the latest version of your graphics card driver and update it, if necessary.

I would very much doubt that, but for the record I have a Nvidia RTX2060 Super with latest drivers installed.
I wonder what others experiencing the same problem have?

1 Like

What font are you using?

EDIT: Notice the cursor (blue) sits way too low. This only happens with the free font “STIX Two Text”. But maybe other fonts cause similar problems?

1 Like

I dont think its a font problem. I’m using times new roman: a very common font. Its a weird bug.

Just to clarify: the problem appears and disappears depending on the change in line spacing. If I put the spacing “exactly”, the problem appears; if I put the “simple” line spacing, the problem goes away.

Documenting some findings to aid developers for debugging.
As mentioned earlier, it appears to be unrelated to font, but occurs when Line Spacing option is set to a custom value, i.e. Exactly.

  • Specifically, issues occur when the value is set to 15/16 pts and above - in my case at least.

  • The last line (or two) in a piece of selected text may not be receiving the adjusted line spacing correctly. This can cause the paragraph/selected text to flow into and overlay a following paragraph.

  • With the custom increased line spacing, the cursor does not completely erase itself during the blink off stage.

  • Also mentioned earlier, other anomalous behaviour, such as selected text being deselected can leave residual half selections is similar to the cursor not erasing itself completely.

  • No Line Spacing issues seen in Microsoft Word for similar values.

image

image

image

image

2 Likes

Reviving this topic from the dead as Muse here already provided a great breakdown of the issue that appears to still persist in the latest version of Scrivener (v3.1.5.1) with Windows 11 (22H2 v22621.2361) and I haven’t seen any solutions or support posted in the past 2 years regarding this.

It appears to be directly related to line spacing pargraph settings, and particularly with “Exactly” as the Line Spacing setting (as opposed to “At Least” for example, which appears to alleviate the issue but introduces the larger issue of having improperly spaced formatting that is not “Exact”).

This is mostly a significant issue for “Scriptwriting Mode” as having “Exactly” formatted line spacing is crucial to the overall layout of the preset formatting of the various Elements (Scene Heading, Character, Dialogue, etc.). It may sound trivial, but it is very distracting to have a “broken” cursor in a program that focuses on that very element as the key input. It’s also difficult to parse highlighted text when editing as the highlight bleeds across half of the adjacent line spacing.

TL;DR it looks super janky in a mid-90s word processor kind of way.

I presume it’s related to specific Windows OS interface as the problem does not exist on latest Mac version of Scrivener (v3.3.3) on MacOS Ventura (v13.6) - but to be clear the issue does not exist in other Windows-based text input interfaces or apps (such as Word, for example, even when adjusting various line spacing options).

Has this been submitted formally as a bug? I’m a big fan of the general functionality of this app as a whole but this feels like kind of a big miss for one of the core feature sets on a widely used platform.

I’m open to any workarounds or thoughts/suggestions anyone might have - thanks in advance for any help you can provide.

Yes, this is something we have extensive notes on, and have put quite a bit of work into already. It is better than it used to be, but still needs more work. It is unfortunately quite difficult to fix these kinds of problems, as a lot of the originate well beneath any kind of code Scrivener itself consists of.

Thanks for the quick response and context. Good to know it’s at least a known issue and potentially in the queue for refinement/fix. But yeah, just a bit of a pain for scriptwriting mode on PC for the time being.

Will try to work around with temporary loose formatting while editing to make it easier to parse at least while in development and then convert the doc back to default “exact” presets prior to compile for sake of actual format needs on the page for output I suppose (or just use my Mac for scriptwriting mode needs where it’s a little more WYSIWYG it seems).

Yeah! I was about to suggest you can probably get away with removing the “exactly” constraint from your Script Settings in composition. It may only slightly impact the page count estimates here and there, but they are estimates anyway. And you are right, there are still some odd layout issues here and there between the text editor and the output in Scrivener for Windows (it is better than it used to be, by a long shot, but there is still some page drift over long scripts). For most things it doesn’t matter much, but for screenplays it does mean considering the editor much more a rough draft experience.