<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Dear Jurgen:</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you for your feedback! Some very interesting ideas - let me think about it for a while.</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
You are right - the overlapping is an issue, and that - at least in my original design - requires separate attributes. The whole thing is complicated enough already ;-) </div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Nevertheless, the code is still in an incubator, so we have some freedom to tweak the APIs.</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-andy </div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div dir="ltr" style="font-family: "Iosevka Fixed SS16", Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="mail-editor-reference-message-container">
<div class="ms-outlook-mobile-reference-message skipProofing">
<meta name="Generator" content="Microsoft Exchange Server">
</div>
<div class="ms-outlook-mobile-reference-message skipProofing" style="text-align: left; padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor; font-family: Aptos; font-size: 12pt; color: black;">
<b>From: </b>Jurgen Doll <jurgen@ivoryemr.co.za><br>
<b>Date: </b>Monday, December 22, 2025 at 01:52<br>
<b>To: </b>Andy Goryachev <andy.goryachev@oracle.com><br>
<b>Cc: </b>openjfx-discuss@openjdk.org <openjfx-discuss@openjdk.org><br>
<b>Subject: </b>Re: [External] : RichTextArea styling feedback<br>
<br>
</div>
<div class="PlainText" style="font-size: 11pt;">Hi Andy<br>
<br>
So your proposal touches on a number of points:<br>
<br>
1. Making the RichParagraph.Builder available via buildParagraph(int index)<br>
<br>
Previously when I was trying to figure out how to customise<br>
RichTextArea for my use case I thought this was needed, however now that<br>
I know the control and implementation better I'm more of the opinion<br>
that it shouldn't in principal be necessary and suspect that it maybe<br>
indicates a shortcoming in the API and implementation ?<br>
<br>
2. Making RichParagraph.getSegments() public<br>
<br>
I asked for this merely as a convenience and your code comment<br>
suggesting it. Otherwise one has to do tedious code like this:<br>
<br>
List<StyledSegment> segments = new ArrayList<>();<br>
try {<br>
exportParagraph( index, 0, getParagraphLength( index ),<br>
true, new StyledOutput() {<br>
@Override public void consume( StyledSegment seg )<br>
throws IOException { segments.add( seg ); }<br>
@Override public void close() throws IOException {}<br>
@Override public void flush() throws IOException {}<br>
});<br>
}<br>
catch ( IOException IO ) { IO.printStackTrace(); }<br>
<br>
With regards to this it would be nice if SegmentStyledOutput and<br>
StringBuilderStyledOutput be moved from the sun package to be accessible ?<br>
<br>
3. You say > "these attributes could not be considered standard"<br>
<br>
Maybe this is true for wavy underlining but I don't think it holds<br>
for text highlighting. So if we can find a solution for the latter then<br>
the former can be accommodated as well. See next.<br>
<br>
4. You say > "The main issue is that these decorations might conceivably<br>
span segments, or apply to parts of a segment, or both."<br>
<br>
Actually I think you mean that the biggest problem is that these<br>
decorations can overlap, like you've so neatly demonstrated, and are<br>
unlike other text attributes which are either on/off or like only one<br>
particular text color. This is the core issue since StyleAttributeMap<br>
can only hold one of any one type of attribute (and also needs to be<br>
typed), but what we need is multiple values for these decoration<br>
attributes !<br>
<br>
The straightforward approach then using the existing API paradigm is<br>
to specify the type as an array in StyleAttributeMap, so maybe we add<br>
something like:<br>
<br>
TEXT_HIGHLIGHT = new StyleAttribute<String[]>( "TEXT_HIGHLIGHT",<br>
String[].class, false );<br>
WAVY_UNDERLINE = new StyleAttribute<Color[]>( "WAVY_UNDERLINE",<br>
Color[].class, false );<br>
<br>
The StyleAttributeMap.Builder gets setTextHighlight( String css )<br>
as well as setWavyUnderline( Color color ) // both are not arrays<br>
and merging is maybe accommodated by overloading the setUnguarded<br>
method with setUnguarded( StyleAttribute, Object[] )<br>
where arrays are merged without duplicates.<br>
Yeah it's ugly/bad, maybe you can improve it ?<br>
<br>
Then update RichParagraph to process them, joining matching adjacent<br>
decorations into one contiguous length as needed.<br>
<br>
I hope these suggestions have some merit and are workable.<br>
<br>
Thanks, regards<br>
Jurgen<br>
<br>
<br>
On Dec 9 2025, at 10:15 pm, Andy Goryachev <andy.goryachev@oracle.com> wrote:<br>
<br>
> Dear Jurgen:<br>
> <br>
> I explored a number of ways we could enable adding<br>
> highlights/squigglies via attributes.<br>
> <br>
> The main issue is that these decorations might conceivably span<br>
> segments, or apply to parts of a segment, or both. The secondary<br>
> issue is that these attributes could not be considered standard (and<br>
> you probably don't want us to codify colors or styles anyway).<br>
> <br>
> One way to do so is described in [0] - basically expose the builder<br>
> within the model. This way the application can simply extend one or<br>
> the other standard model to add app-specific attributes. You can see<br>
> an example in [1].<br>
> <br>
> Would that work for you and everyone else? What do you think?<br>
> <br>
> Thank you<br>
> -andy<br>
> <br>
> <br>
> [0] <a href="https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1966*issuecomment-3634052681__;Iw!!ACWV5N9M2RV99hQ!KNUsqIxjKc5gFAUQruuD1MvS7GZLjTAJIv4mBXqBzOLEfTF19mXFoOiOfWL9Z5bfFMryPk80wYMHpvWZEF6SROg$" data-outlook-id="7fd78835-5096-499c-a9e7-4ecec2545ca0">
https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1966*issuecomment-3634052681__;Iw!!ACWV5N9M2RV99hQ!KNUsqIxjKc5gFAUQruuD1MvS7GZLjTAJIv4mBXqBzOLEfTF19mXFoOiOfWL9Z5bfFMryPk80wYMHpvWZEF6SROg$</a><br>
> <br>
> [1] <a href="https://urldefense.com/v3/__https://github.com/andy-goryachev-oracle/Test/blob/paragraph.enhancements/src/goryachev/research/RichTextArea_CustomModel_8366198.java__;!!ACWV5N9M2RV99hQ!KNUsqIxjKc5gFAUQruuD1MvS7GZLjTAJIv4mBXqBzOLEfTF19mXFoOiOfWL9Z5bfFMryPk80wYMHpvWZD6_Xark$" data-outlook-id="8e9d2d87-cdbe-42c5-ab1c-6e265dab04ee">
https://urldefense.com/v3/__https://github.com/andy-goryachev-oracle/Test/blob/paragraph.enhancements/src/goryachev/research/RichTextArea_CustomModel_8366198.java__;!!ACWV5N9M2RV99hQ!KNUsqIxjKc5gFAUQruuD1MvS7GZLjTAJIv4mBXqBzOLEfTF19mXFoOiOfWL9Z5bfFMryPk80wYMHpvWZD6_Xark$</a><br>
> <br>
> <br>
> <br>
> From: Jurgen Doll <jurgen@ivoryemr.co.za><br>
> Date: Tuesday, August 26, 2025 at 08:06<br>
> To: Andy Goryachev <andy.goryachev@oracle.com>,<br>
> openjfx-discuss@openjdk.org <openjfx-discuss@openjdk.org><br>
> Subject: [External] : RichTextArea styling feedback<br>
> <br>
> Hi Andy<br>
> <br>
> I've been looking at the RichTextArea incubator feature and am<br>
> providing feedback wrt the styling aspect of it.<br>
> First off though, thank you for all the effort you have put into this<br>
> so far and I'm looking forward to when this matures.<br>
> <br>
> Some background: since I use the RichTextFX library in my real world<br>
> application I wanted to see how easily I could refactor my application<br>
> to use RichTextArea instead, and then provide you with feedback. Here<br>
> I'm focusing just on a simple editor control in my application that<br>
> has some basic styling options (bold, italic, underline, and text<br>
> color) available for the user while the editor indicates any<br>
> misspelled words as they type with a wavy underline.<br>
> <br>
> I used a standard RichTextArea with its default RichTextModel and<br>
> you'll be pleased to hear that without too much fuss I was able to<br>
> read & write using StyledInput & StyledOutput, as well as convert the<br>
> styling options part of my text editor control. However styling for<br>
> spellchecking didn't go as well.<br>
> <br>
> So based off my experience with trying various things I recommend the<br>
> following API enhancements:<br>
> <br>
> The following StyleAttributes should be added to StyleAttributeMap: <br>
> INLINE_STYLE, STYLE_NAMES, TEXT_HIGHLIGHT, and WAVY_UNDERLINE. At<br>
> the moment none of these are easily or directly available, and I<br>
> believe from a user perspective that they should be.<br>
> Consider splitting StyleAttributes into TextAttributes and<br>
> ParagraphAttributes then INLINE_STYLE and STYLE_NAMES can appear in<br>
> both. Possibly then also have a DecoratorAttribute if needed for<br>
> TEXT_HIGHLIGHT and WAVY_UNDERLINE, if that'll make implementation<br>
> easier but it should I believe from a user perspective still go<br>
> into/through StyleAttributeMap as all styling should preferably be in<br>
> one place.<br>
> The methods applyStyle and setStyle in RichTextArea should have a<br>
> boolean undo parameter like replaceText.<br>
> There's also the following issue that I noticed. When typing text, in<br>
> the middle of a sentence, to extend a word that's styled then the<br>
> typed text is not being inserted using the styles of the preceding text.<br>
> <br>
> There are some other obervations regarding other aspects of<br>
> RichTextArea that I hope to give feedback on soon as well.<br>
> <br>
> Thanks again, regards<br>
> Jurgen<br>
</div>
</div>
</body>
</html>