JDK-8319050 : Text/TextFlow.caretShape() and .rangeShape() wrong in RTL orientation
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: jfx21
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-10-27
  • Updated: 2024-11-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8343557 - ☂ RTL Issues in Controls
Relates :  
JDK-8318095 - TextArea/TextFlow: wrong layout in RTL mode
Relates :  
JDK-8330559 - Trailing space not rendering correctly in TextFlow in RTL mode
Relates :  
JDK-8219183 - Caret of the TextField or TextArea style and sharp
Relates :  
JDK-8300569 - ☂ Missing APIs related to rich text control
Relates :  
JDK-8319844 - Text/TextFlow.hitTest() is incorrect in RTL orientation
Description
When TextFlow is set to RTL node orientation, not only the layout is incorrect (see JDK-8318095) but also

caretShape() and
rangeShape()

methods return incorrect values.

To reproduce, launch the attached code and click left mouse button to see the caret shape, or right mouse button to see the range shape of the whole text.  The paths will also be printed to stdout.

A similar issue is present in Text.
Comments
Since trailing space rendering issue need to be resolved first, parking this issue for now
18-04-2024
Created JDK-8330559 for fixing the trailing space rendering issue
18-04-2024
Yes, it makes sense to expect range shape to enclose the character. In fact that is what it is supposed to do right! I think proceeding in this direction seems logical.
10-04-2024
[~kpk]: It feels like a bug to me. I think the expectation is that if a range shape is requested between positions that encompass that space (or any other character), that is, if the range is specified by the indices immediately preceding and immediately following said character (regardless of order) it should return a shape that encloses the character. There might obviously be other considerations for e.g. grapheme clusters, but I think the range shape should always work this way. I think you might have found the root cause though. What do you think?
08-04-2024
The behaviour mentioned in pt.2 is because of the space present after ":" in the text ("Arabic: "). The colon together with space is considered as RTL text. The positions array returned from the OS (CTRunGetPositions) for the text run which contains : and space has negative value of the width of space. This negative value is considered while calculating the position of caret shape but not considered while calculating the value of range shape. Hence the caret position gets subtracted from starting position of the text run by negative value and displays to the left of the ":". Additionally there is space between ":" and first letter A of "Arabic" as well. So I'm not entirely sure if it is an issue or not, if yes in which case this needs to be considered as an issue. Need to do more investigation on this. Please let me know if you have any thought on this [~angorya].
08-04-2024
Thanks for updating the tests [~angorya]. On running the both the tests for the first time, both of them looked fine but when I ran the Text test again, Text is positioned with some offset. I will check if I can find the exact issue and revert back. I see the same issue in TextFlow you mentioned above in 2nd point.
08-04-2024
Thank you [~kpk] for looking at this. I've changed the tests again to avoid positioning offset. We can't use Group because we want to exercise the wrappingWidth when one resizes the window. There is a bit of irregularity with the current master code, please take a look: 1. Not sure why Text is positioned with an offset still, but perhaps it's the problem with the test. In any case, moving the mouse over re-generates the range shape and caret shape at the hit under mouse cursor in both tests 2. Something is fishy with the caret shape (see the new screenshot). https://bugs.openjdk.org/secure/attachment/108872/Screenshot%202024-04-05%20at%2014.14.02.png Updated tests: https://bugs.openjdk.org/secure/attachment/108874/TextFlow_CaretRangeShape_8319050-1.java https://bugs.openjdk.org/secure/attachment/108873/Text_CaretRangeShape_8319050-1.java
05-04-2024
[~angorya], while fixing the issue I observed that if we add caret and range Path variables to the TextFlow itself, then we see the issue mentioned here. If we add the Path variables to a group along with TextFlow to a Group container, then Im not observing the issue. So I'm not sure if we are using the range shape values correctly or not. Any thoughts on this?
05-04-2024
[~angorya] thanks for updating the test.
06-02-2024
[~kpk]: the test Text_CaretRangeShape_8319050 has a bit of a problem - it might offset the caret and range shapes relative to the text inside of Text node. I've updated the test; it still has some issues (it needs more precise positioning of the Text node) but it should illustrate the problem. Sorry about that.
02-02-2024
Sure Andy, I will look into this.
02-11-2023
Karthik, would you mind taking on this bug? It sort of blocks RTL development in RichTextArea and bidi navigation fix, I would really appreciate if we could get this sorted out first. Thank you!
31-10-2023