• Type: Task
• Component: javafx
• Sub-Component: controls

• Priority: P4
• Status: In Progress
• Resolution: Unresolved

• Submitted: 2023-01-18
• Updated: 2024-11-15

Other
tbdUnresolved

Follow-up from Gary Bentley: So for JTextComponent, I would say that any new text component should have the same features as that supported by JTextComponent. If you compare javafx/TextArea and swing/JTextComponent they have very different approaches. For TextArea there is a presumption that the user wants a scrollpane wrapper, but this isn't always true so instead TextFlow has to be used. Features I think TextFlow needs (or any text component, note this list isn't exhaustive because the features I desire are limited to a specific use case, that is a person editing text only in a single component, other uses of RichTextFX say have different use cases and feature needs): - Access to the view or model and being able to move between the two. - Control of the caret visual properties such as color and shape. Similarly for the selection, there is some control in TextInputControl but that is purely for text. - TextFlow uses Nodes to represent it's model but there is no associated "document model" thus it makes managing the underlying information difficult. See javax.swing.text.Document, org.fxmisc.richtextfx.model.StyledDocument and com.gluonhq.richtextarea.model.Document for more details. - TextFlow doesn't allow for a first line indent. You would be amazed at the number of authors who want this feature. - Printing support, javafx.print assumes that you want to print the Node as is but text needs formatting and pagination that is related to the text. - There is no way to define how the caret should be moved around the text (or Nodes for TextFlow). In TextInputControl there is nextWord/previousWord but they seem to assume what a word is, presumably based on a default locale BreakIterator (but I don't know). So I would need to override this behavior in the sub-class rather than providing a way to let the component know how I would like caret movement to occur. - On a broader point being able to set a locale for Node would be useful. - There is no way in TextFlow to provide key/action mappings. This becomes a complex area for rich text, for example turning a number of selected Nodes into something suitable for cut/copy/paste is not straight forward. - Position tracking, in Swing this was provided by the Document model, see https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/javax/swing/text/AbstractDocument.html#createPosition(int) this type of thing is vital for being reactive to the user making changes to the model, especially when you can then map that position to the view. This isn't an exhaustive list however, it's only my view of the features I think JTextComponent has and I wish TextFlow had. For the decorations/margins, I think both paragraph and text run decorations are desirable. Consider a code text area, it would be useful to select a piece of text and assign "something" to it and then have a decoration be applied to the text and thus it be visually marked. However this would be useful at any level of granularity, from the entire document all the way down to each node or even single text characters. My own preferred way of handling any new text component would be to have a "document" class that models the content and then I provide to the text component a way of converting each element within the document to a visual Node. RichTextFX sort of takes that approach which works very well but it may not be suitable for all use cases, for example rendering HTML elements. 21-02-2023 From Gary Bentley: I don't think APIs is the way to think of it. A better approach is to determine what are the desirable features of a text component and then work from there. The Swing JTextComponent is a good model to use, especially its separation of view and model and the ability to work with both and interchange between them, for instance methods such as modelToView and viewToModel are indispensable for developers who want to manipulate the view based on the text. So a good first step is to have feature parity with JTextComponent. Further features that would be useful are things like paragraph decorations, such as the margins RichTextFX uses and the decorations that Gluon's RichTextArea uses. Support for arbitrary Nodes positioned within the text is useful and parity with the text features offered by HTML such as word spacing, letter spacing, line spacing, alignments, indentations, fonts and so on. Another useful feature would be support for CSS styling (as RichTextFX does) and allow for arbitrary pseudo classes to be assigned to text. Give the developer access to each text component so that styling can be overridden. Scalability should be a primary concern, I had a user tell me that the RichTextFX text component was slowing down, I later found out that the person had 200,000 words in the component. An undomanager should be a core feature with a simple interface for both the end user and developer, this includes having access to the undos available. Finally, accurate positioning of the text within a scrollpane is needed, so I should be able to have a text position, get the view position then move the view to the exact location of the text. 17-02-2023 From Scott Palmer: When I was experimenting with a program to generate titles for videos the ability to control the spacing between letters (not kerning, but tracking) would have been helpful. E.g. animating something like this: Title T i t l e T i t l e T i t l e I don't recall everything I encountered in that project, but I believe all the basic font metrics about baseline and ascenders/descenders would help. A FontChooser would be useful. Applications can always code their own, but the same can be said for ColorPicker. It doesn't look like there is one available even from 3rd-party libraries like ControlsFX. Going from a Font object to CSS -fx-font-size, -fx-font-family, -fx-font-weight, -fx-font-style doesn't always work as I've already mentioned. The Font object doesn't have a method to get the font weight and there is no -fx-font-name style. Setting -fx-font-family doesn't always result in CSS that successfully selects the desired font if used in combination with -fx-font-style and/or -fx-font-weight. Sometimes adding CSS for weight or style will cause a completely different family to be used which can look quite drastic when a variable width font is substituted for a fixed-width font just because you tried to make something bold. Also FontPosture only has ITALIC and NORMAL, but CSS -fx-font-style has 'normal', 'italic' and 'oblique' - There is no way to ask for 'oblique' from code and the FontStyleConverter will convert "oblique" to REGULAR, even though "oblique" works in CSS to get a slanted font. Asking about caretBlinkRate, I'm not sure. I imagine only one caret should ever be visible, with the exception of a rich text control that supports multiple simultaneous insertion points, like many code editors. In that case there would still only be one rate at a time even though there are multiple carets. My point being there should never be a need for multiple rates to be active at the same time, so maybe you could get away with a global rate. I can't think of a need for multiple rates, but maybe someone else can. 17-02-2023 From yosbits: Lack of API and CSS rules to specify letter spacing for Text https://developer.mozilla.org/en-US/docs/Web/CSS/letter-spacing Text needs to support letter spacing - JBS 17-02-2023 From yosbits: Variant non of wrap text mode overflow-wrap: anywhere; hyphens: manual; hyphens: auto; https://developer.mozilla.org/docs/Web/CSS/overflow-wrap https://developer.mozilla.org/docs/Web/CSS/hyphens 17-02-2023 From yosbits: Lack of a clever edit buffer implementation. javafx's standard controls TextField and TextArea are worse at handling large text than Swing's GapContent due to their naive implementation. The choice of editing buffer algorithm will be a feature of each text editor engine, but we feel that standardization of the interface and default implementation should be considered. 17-02-2023 From yosbits: Standardize VirtualFlow for use in text editors (TextArea). Many text editor libraries have their own implementations, but appear to have few functional features. javafx's standard control TextArea, without VirtualFlow, is not good at handling large text. 17-02-2023 From yosbits: Problems that occur in implementations of functions implementing syntax highlighting Syntax highlighting implementations often use regular expressions for lexical analysis, but may not be able to use the standard API java.util.regex.Pattern as a regular expression engine for the following reasons. Potential StackOverFlow risk due to the use of recursive calls in implementations when there is group repetition in the grammar definition. https://bugs.openjdk.org/browse/JDK-6882582 17-02-2023 From Joe Mwangi: Not sure whether this is out of scope (but if it is, it can be deleted), but my wishlist is to have font-metrics, line metrics access in javafx canvas/graphicscontext. Such as https://docs.oracle.com/javase/7/docs/technotes/guides/2d/spec/j2d-fonts.html. Current limitation is that one cannot justify text or do multiline text, mixed font text measurements in canvas/graphicscontext. 17-02-2023 From Scott Palmer: I've been using RichTextFX to make my own code editor/IDE. I see that you have asked that project specifically on GitHub, excellent. One thing that I wanted to do was to use a font like Fira Code that combines characters such as != or >= into a single glyph, but there are no APIs to request that JavaFX render those optional ligatures. Swing APIs automatically do. In fact just implementing some basic font selection has been tedious. Getting the font family from a Font object and trying to use it in CSS to specify -fx-font-family simply doesn't work sometimes. Trying to filter the list of available fonts to show only those that are fixed-width is tedious. I tried to hack something by measuring a couple different characters from the font that would normally be different widths, but this is an unreliable hack. Allowing the user to choose a preferred font and then configuring components to use it via a CSS stylesheet is simply more difficult than it should be. A few years ago I contributed the changes to make the tab-width configurable, which helped with my project a little bit. Other APIs are needed to better control line spacing and measure font baseline offsets and that sort of thing. I see there is an issue for caretBlinkRate, what about changing the caret shape? E.g. block, underscore, vertical bar, etc. Should the block be solid or an outline? Why is caretShape read-only? Why does it return an array of PathElements instead of simply a Shape which by default would be a Path? More control of kerning and general spacing might be nice. I've wanted that in the past, not for a rich text control, but for doing video title. I can see how the two needs overlap though. I recently asked here about rendering emojis. That's currently very unreliable and broken. Getting something to work consistently cross-platform is not easy. Sometimes emojis are rendered in color, other times not. Mac renders color emojis in gray and at the wrong size (since the sub-pixel rendering was turned off to match macOS). On Windows the emojis are never in color. 17-02-2023