Font Demo Text Editor. move to beginning/end of line doesn't stay on correct line


#1

I’m testing this on mac but I’m not sure if it’s a mac only issue. Tested with the latest Font demo on El Capitan (seen similar behaviour on Sierra). The jumps are invoked with command left/right arrow

I originally intended to just report this issue that’s been around for a long time:
1.) When the last line of text has a line feed at the end (meaning there’s one more line after it with nothing on it) the jump to end of line will bump the caret down to the last line with nothing on it.

When I attempted to verify that the latest dev still had that issue, I discovered there are now more problems with it. (*Edited to show how the current font affects this behaviour)
2.) Jump to beginning of line and jump to end of line often bumps the caret up one line (maintains respective beginning/end, just wrong line).

Bump up behaviour based on font, e.g.:
Bodoni 72 Oldstyle: every line bumps up
Bodoni 72 Smallcaps: No lines bump up
Chalkboard: Only some lines bump up.

Note issue number 1 does not appear to be affected by font choice.

*Edit again:
Issue #3
Same setup as for issue 1, but now the cursor is on the second last line of text and is at a cursor position further right then the last line of text has, a down arrow will jump the last line of text and land on the very last line (the one with no text).

e.g.
This is the second last line of text. We press down arrow here.
This is the last line of text.
<>this is a line with no text and where the cursor jumps to<>


#2

I’ve sorted out the “bump up” (#2) issue. It’s just a float/int rounding problem with getCaretRectangle. I created a new float version of that method and call it from the various “move” methods and the problem goes away. Specifically it’s the line height that gets mixed up when iterating in indexAtPosition.


#4

My previous post was way off so I just deleted it to clean up the thread.

With a better look at issues 1 and 3, it seems indexAtPosition just needs some handling for new lines. I’ve added the following check which fixes the behaviour. I’ve played around with it a bit and it doesn’t appear to have any adverse effects on other actions. Will continue to test and let you know if an issue pops up.

            if (i.lineY + i.lineHeight > y)
            {
                if (i.lineY > y)
                    return jmax (0, i.indexInText - 1);

                if (i.atomX >= x)
                    return i.indexInText;

                if (x < i.atomRight)
                    return i.xToIndex (x);
                
                //This is the new check to handle new line
                if (i.atom->isNewLine())
                    return i.indexInText;
            }

#5

Thanks, I’ll take a look and see what I can do!


#6

Thanks Jules! Your fix is working well. Did you happen to miss issue 2 though? With certain fonts the move to beginning/end of line will bump the cursor up one line. “Bodoni 72” is an example. Btw, I noticed in your commit message you mentioned “clicking” where in my tests it’s all been with keyboard movements. For issue 2 I use cmd->left arrow and cmd->right arrow. Also might be notable that I’m not on a high-dpi monitor. My resolution is 2560x1440.

My test fix was to add a new getCaretRectangleFloat and replace all occurrences of “getCaretRectangle().toFloat()” with the float version.

Rectangle<int> TextEditor::getCaretRectangle()
{
    return getCaretRectangleFloat().toNearestInt();
}
//getCaretRectangle is an override so created new method instead
Rectangle<float> TextEditor::getCaretRectangleFloat()
{
    Point<float> anchor;
    auto cursorHeight = currentFont.getHeight(); // (in case the text is empty and the call below doesn't set this value)
    getCharPosition (caretPosition, anchor, cursorHeight);
    
    return { anchor.x, anchor.y, 2, cursorHeight};
}

#7

sorry, yes, I did forget about your other point - will have a look today…


#8

No problem. The latest fix looks good here. Thanks!