Unintentional comedy? (Extra large cursor)

Maybe just a quirk of Scrivener? Not sure. Occurs when you increase paragraph spacing sufficiently. I know I’m a very persnickety writer, but such things distract me! :open_mouth: :blush: I’m afraid it’s going to turn around, decide that it’s King of the walk and eat my text or something.


:mrgreen:

Welcome to the iOS text system. You’ll only see that when you are on the last line of a paragraph with paragraph spacing, though. The problem is this:

  • On both iOS and macOS, Apple, for some bizarre reason, has the text cursor match the entire height of the line, not just the text within that line. So, if you have double line spacing, bam, the cursor is twice as tall as the text. If you have paragraph spacing after, then it descends below the text on the last line of the paragraph. You can see this for yourself in TextEdit on the Mac. Just type in a paragraph, change the one spacing to 2x, and place the cursor in the text somewhere. (Or add some paragraph spacing after and place the cursor at the end of that paragraph.)

  • In Scrivener for macOS, I have some pretty hardcore code that works around this. Essentially, I intercept cursor drawing, do all sorts of line spacing calculations, and size the cursor myself rather than relying on Apple’s giant cursor.

  • On iOS, however, Apple has not exposed the cursor drawing methods. This means that developers outside of Apple have no way of changing the cursor height. Except… There is a -caretRectForPosition: method. And what does that do? Boom! It determines the exact height, width and placement of the cursor. So all I need to do is override that and adjust the height, right? Well… You’d think so, and in theory, yes. And that’s exactly what I did in early betas. But it turns out that Apple’s code is messed up, and they are - for some other bizarre reason - calling on the method that determines the text cursor size and position in their code that draws the little blue highlights when there is a potential QuickType completion. So, if I override that method to change the cursor size, the QuickType blue highlights get drawn in completely the wrong place.

There’s no solution for this, as these are all Apple bugs. But I hate the cursor towering over the text, so I at least centred it on the line (changing the position of the cursor doesn’t seem to break QuickType highlights, only changing its height). For the most part, this looks good, but there are still circumstances - such as when the cursor is in the last line of a paragraph that has spacing after it - where it till looks a little goofy, especially if you increase the paragraph spacing enough.

In general, the iOS text system is very buggy. I’d say about 10% of my text code consists of workarounds for Apple bugs. But at least there is a rich text system these days…

Ah. No worries then. I just increased the paragraph spacing to avoid doing double returns between paragraphs in a document. When I’m journaling/outlining a story, I use web-style text: no indent, spaces between paragraphs. When drafting, I use traditional book format: indent, no spaces between paragraphs. Another little psychological trick to trick the brain into shifting gears.

But I can quite easily just hit return twice. Maybe future iterations of iOS will fix this.

Thanks.