JDK-8092278 : Text should have API for selecting group of characters based on their position similar to the DOM's Range.
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2013-03-19
  • Updated: 2023-08-25
  • Resolved: 2023-08-25
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
tbdResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Text and/or TextFlow should have an API for getting a character or group of characters based on their position, similar to the DOM's Range. (See: http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html ) . This is very useful for enabling features like text selection, copy-pasting, and getting the characters under the pointer/cursor during hover/click events. 

My use case: I am developing an application for learning foreign languages via reading texts. A major component of this is that the text the user has chosen will be displayed, and hovering over a word will cause a pop-up dictionary to bring up suggested definitions for the word under the cursor. I also have other plans for different actions a user can take on the word under cursor, ie bringing up a context menu, etc. There are certainly workarounds, such as splitting up each word into a seperate text node, but this becomes much more difficult in a language like Japanese in which words aren't delineated in a text by white space. There are certainly parsers, such as Mecab for Japanese, but implementing these parsers for each possible language is impossible (it would be necessary to implement Mecab for Japanese, a different one for Chinese, another for Korean, etc), also, the parsers are far from perfect and fall down quite frequently on things like prefixes and suffixes, verb tense, etc. The easiest solution, and one used by the popular browser pop-up dictionary Rikaichan (http://www.polarcloud.com/rikaichan/) and all the others whose source code I've looked at is to get the character under cursor, then work forward through the string, comparing the possibilities against entries in the dictionary until the entries come up blank or the end of the line is reached. I plan to make my application capable of using several popular opensource dictionary formats, such as StarDict, for which dictionaries are widely available on the internet in hundreds of languages, and then have the user provide their own dictionaries for the language(s) of their choosing, thus avoiding the problem of needing multiple parsers. 

I have noticed that the TextArea and TextField have some methods for dealing with this, though I don't know if it's possible to get a Selection from the text like the DOM's range, by providing two sets of x,y coordinates. This can be useful, for grabbing text without it being explicitly hovered, clicked or selected. Still, Text and TextFlow do not seem to have any API in this regard at all. Thanks.
Comments
Closing this issue since we have Text.hitTest() and TextFlow.hitTest() since 9. For actually selecting a range of characters, one can use TextField/TextArea selection. Alternatively, if working with Text/TextFlow, one can use rangeShape() and add it (wrapped in Path) to the enclosing container.
25-08-2023

Created #RT-29257 for tracking hit_test API in Text.
28-03-2013

Good to hear! Please do not hesitate to ask for any help either here in the jira or in the mailing list <openjfx-dev@openjdk.java.net>. I think it would be better to file a new Jira asking selection/hit test public APIs in Text and use this jira to track the same support for TextFlow. Note that other developer working on editing capabilities for Rich text, see http://fxexperience.com/2013/02/interview-with-tom-schindl-2/
28-03-2013

Making public API for those hit_test methods would be an excellent start, and would give me most or all of what I need. What you say makes perfect sense about the DOM's range API being a better match for TextFlow. As for community contributions, I'm going to be working with text quite a bit as I move forward, and while I'm still getting my footing for right now, later if I feel like I'm able to contribute anything useful back upstream I will certainly let you know.
27-03-2013

Hi, If I'm understood correctly you need a hit test API ? (You need to know the character index given a x,y offset - is that right ?) For Text, the DOM range API would be overkill. This node already has all the support for what you are asking (but it is not exposed by public API). See impl_hitTestChar, setImpl_selectionEnd, setImpl_selectionStart, getImpl_selectionShape, etc Offerring public API for these functionally makes sense to me (and we should be able to do it for JFX 8) As for TextFlow, there I think the DOM range API would be a good match. But unfortunately we don't have anything implemented yet (as we don't have editing support for rich text in JFX 8 plan). Unless we receive a contribution from the community, I find unlikely we will be able to do anything in this area for JFX 8. see RT-28485 for some extra information.
26-03-2013