Greetings.

I am collecting requests for missing/incomplete APIs needed for implementing a rich text editor, see https://bugs.openjdk.org/browse/JDK-8300569

I searched through your issue tracker and added all the JBS tickets mentioned (hopefully, all of them), but there exists a possibility that you might need other APIs for which no JBS ticket has been created.

You can respond here or in JBS ticket.

Thanks.

-andy

Jan 25 '23 23:01 andy-goryachev-oracle

@Xiaobaishushu25 please post as a separate issue, thank you.

Jan 26 '23 12:01 Jugen

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.

Jan 26 '23 20:01 mambastudio

Thank you @mambastudio . We already have https://bugs.openjdk.org/browse/JDK-8090775 for this problem.

Personally, I used a single static Text/TextFlow instance for that purpose.

Jan 26 '23 20:01 andy-goryachev-oracle

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

Jan 27 '23 08:01 yososs

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.

Jan 27 '23 08:01 yososs

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.

At least the text buffer of JavaFX standard control should be able to handle text with a length equal to or greater than that of Swing. Solving this problem would reduce the need for third-party libraries for his RichTextArea engine, but would improve the reputation of JavaFX technology.

Jan 27 '23 08:01 yososs

Enhanced wrap text mode variation

The importance of these wrap rules may be perceived differently in languages that separate words with whitespace and those that do not (CJK).

overflow-wrap: anywhere;
line-break: strict;
hyphens: manual;
hyphens: auto;

https://developer.mozilla.org/docs/Web/CSS/overflow-wrap
https://developer.mozilla.org/docs/Web/CSS/line-break
https://developer.mozilla.org/docs/Web/CSS/hyphens
Soft hyphen support for TextFlow - JBS

Jan 27 '23 09:01 yososs

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

Jan 27 '23 13:01 yososs

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.

This looks very useful; looking forward to making it happen

Jan 30 '23 15:01 leewyatt

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.

Feb 14 '23 00:02 garybentley

Gary:

Thank you so much for a very detailed list! As we all know, it is a very long list.

Could you clarify a few points please?

So a good first step is to have feature parity with JTextComponent. What is missing, specifically?

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. What kinds of decorations? Are these decorations applied to the whole paragraph or individual text runs?

Thanks again. -andy

From: Gary Bentley @.> Date: Monday, February 13, 2023 at 16:37 To: FXMisc/RichTextFX @.> Cc: Andy Goryachev @.>, Author @.> Subject: [External] : Re: [FXMisc/RichTextFX] Q: Any missing APIs in JavaFX which are needed for this project? (Issue #1167)