Rich Text Editor in avalonia

[fengyinyong]

I need a rich text editor in my avalonia project，just like the rich text editor in WPF, witch can add words、images.....
I have read the Issue #4410 and https://github.com/AvaloniaUI/AvaloniaEdit/.
But they do not fulfill my needs

[kekekeks]

FlowDocument text model is being worked on

[fengyinyong]

When work it out，please tell me in this issue. Thank you very much.

[dragonman117]

FlowDocument text model is being worked on

Is there any chance we can get an indication of where this work is going on? I don't really see it on any of the roadmaps I've been able to find, and I don't see any branches that appear to be showing any active work for this feature.

[danwalmsley]

@Gillibald is actively working on it

[Gillibald]

#5461

[warappa]

Is there any news on this topic as PR #5461 was abandoned?

And as demand was mentioned in the PR: What's your preferred way of expressing demand? Via thumbs-up on this ticket? Somewhere in discussion section?

Anyway, thanks for your efforts!

[maxkatz6]

Rich TextBlock with inlines from #5461 was already added after multiple other PRs. As well as selectable TextBlock.
RichTextBox specifically wasn't yet done. Current text rendering with IME support is in higher priority. After that work on RichTextBox can be started. @Gillibald might know better estimates.
So, since it is already planned to be added earlier or sooner, I don't think there is a point in voting.

Meanwhile, AvaloniaEdit is still a working alternative for some use cases.

[JesseDietrichson]

@Gillibald @maxkatz6 Is there any way we could discuss bumping the priority of RichTextBox + Flowdocument. Root is interested in funding this effort.

Would love to chat about this more. My email is [email protected]

[Gillibald]

Please contact us at [email protected] and we can setup a meeting to discuss your requirements and what we can do to achieve them.

[JesseDietrichson]

@Gillibald FYI, I reached out to the above email.

Thanks!

[parentelement]

Not sure if people are still waiting on this but I finally decided to just build my own. I explored MAUI, which doesn't have one and doesn't have native Linux support, Uno doesn't have one, and Avalonia doesn't have one, so I started building my own based on my modified version of the RichTextKit library. I'm still working on features and working through some bugs and I still to add some hooks and scroll bars but currently I support:

• Keybaord navigation and mouse interaction.
• Text Styles (Bold, Italic, Underline, Subscript, Superscript, etc... everything RichTextKit does)
• Merging styles (Applying a style to a selection merges that style with all runs in the selection - RichTextKit doesn't do this, it's a modification).
• Mouse wheel scrolling - code based scrolling.
• Copy/Paste/Undo/Redo
• Fonts, Font Sizes
• X and Y Scaling (zoom in/out)

There's a lot of work still to be done and I'm building on top of my own abstraction that'll allow me to build the same control for other platforms as well, but I'm starting with Avalonia. Here's a brief rough video of it working.

https://youtu.be/AKlW6Cl5SuU

[timunie]

@parentelement that looks really awsome. If the control will be open source, consider to add it to awsome avalonia 👍

[parentelement]

@timunie Thanks! Since I recorded that video I've fixed a few bugs, started breaking into a proper component structure, and got scrolling working with scroll bars. There are still quite a few bugs and some odd behavior, and also a memory leak issue due to how RTK handles Style caching which doesn't account for rendering/UI happening on different threads (the StyleManager is a ThreadLocal on a static object). I also have a lot of work to do in finalizing the API so I can provide a simple way to control the document while still allowing low level access if someone wants to build something custom on top of it.

The contents of the document are stored in a structure close to that of Flowdocument but not exactly, so I need to enhance RichTextKit to provide enumerable access to the content and styles so getting the text out is easier. By default it only exposes the text as a plain text block.

Other things I'm working on:

• Configurable and collapsible paragraph margins to allow enabling double space between paragraphs
• Configurable paragraph indent (which isn't currently supported at all) so first lines can be indented
• Enumerable access to the document content (likely a yield/return that will transform into a common format)
• A way to load content so it can be populated either directly in the control or via code
• Copying and Pasting styles (right now copy/paste is plain text only)
• Image support (This likely won't make my first release when I do it)
• Bug fixing - scrolling via keyboard / caret navigation and extending selection ranges, fixing some style merging issues
• A machanism for notifying consumers where a style property has more than one value in a selection range (such as more than one font in a rage so a font combobox can react accordingly).

It already supports page margins, left, right, centered text. Looking into Justified text and possibly assigning margins at the paragraph level.

Also, as a separate project I'd like to provide some import/export support for things like HTML/PDF/RTF/OpenXML.

The intent for sure is to at least publish and open source my modifications to RichTextKit as well as the core layer that provides all of the interaction, shortcut handling, etc. This would allow anyone to easily build a UI control on top of it. I haven't decided yet whether I'll open source the final editor control. I likely will for Avalonia, but may keep it closed for Uno and Maui.

[parentelement]

Couple more points to add... I stress tested it with a couple of documents, one with 200,000 words and the other with 2.4 Million words. Of course memory consumption gets fairly high at that point but still under 1 Gig total for the whole application and the operation was still buttery smooth. One thing I want to figure out though, and I'm not super familiar with Avalonia, but right now it uses the feature lease to get access to the Skia canvas.

The problems there is that, for one, Skia isn't guaranteed to always be the renderer that Avalonia uses. And secondly, I have no control over the individual rendered unit because everything is being don't together, so I don't have a good way to do caching, meaning I'm having to do some recomputation and render the document within the visible bounds every frame.

While I'm happy with the performance, I think I'm going to change my control to use a WriteableBitmap and construct my own Skia canvas to draw on it. This will allow me to continue to use Skia even if it's not the Avalonia renderer. It will also allow me to cache the document bitmap and just re-render it instead of redrawing it. And finally, the caret then becomes a separate layer that's just composited on top of the document (again allowing me to cache the document bitmap because it doesn't matter if the caret is visible or not).

[Gillibald]

In general Avalonia is just lacking a proper document model. If you were using the TextFormatter you would get richer features with optional virtualization support.

[parentelement]

@Gillibald 100%. If I was developing purely for Avalonia I'd probably just go the route of porting the WPF controls directly, but I want to support Maui and Uno as well. Fortunately, RichTextKit already essentially provides what I need because I'm only actually rendering what's within the visible bounds so rendering isn't an issue. To add, though, Skia by itself isn't always fantastic for text. RTK uses Harfbuzz for text shaping and ligature support which makes supporting the whole set of Unicode (and even emojis) possible more richly than what TextFormatter can provide.

[Gillibald]

TextFormatter supports Unicode 13 and is optimized for memory consumption. Its API is designed to be used to support arbitrary sources of text and supports random access so virtualization is no issue. I just wanted to inform you.

[parentelement]

Good to know. I'll have to see if it's been ported for Maui and Uno as well.

…

On Tue, May 2, 2023, 8:37 AM Benedikt Stebner ***@***.***> wrote: TextFormatter supports Unicode 13 and is optimized for memory consumption. Its API is designed to be used to support arbitrary sources of text and supports random access so virtualization is no issue. I just wanted to inform you. — Reply to this email directly, view it on GitHub <#4625 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH7IT7WVOWKRGLGY3UBVI7DXEEEX5ANCNFSM4Q7SIJ4A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[parentelement]

Looks like TextFormatter is only ported to Avalonia, but I'm pretty happy with RTK. Making some pretty decent progress.

https://youtu.be/Mutb0SWRjwQ

[doublecount]

@parentelement
saw your great work on RichTextBox. Is there already any plan for release, what kind of license do you consider?

[parentelement]

@parentelement saw your great work on RichTextBox. Is there already any plan for release, what kind of license do you consider?

It's in progress. My focus has been cleaning up some bugs. Tentatively, the plan is to release it as two separate packages. One will be open source for sure. That have the RTK fork along with the core interface library and I'll have adapters for each target platform starting with Avalonia.

[hematec]

@parentelement
you've done an impressive job on this!
Are there any news for a planned release date?

[parentelement]

@parentelement you've done an impressive job on this! Are there any news for a planned release date?

Thanks, appreciate the kind words! There's no specific time frame yet. I'm still working on it but it's somewhat sporadic as I'm the only contributor currently.

[mateli]

@parentelement I suggest that you decide what to open source asap so that others can contribute. Also I do not think that a fully functioning rich text editor is required for making a first release. Instead deciding on a minimal viable functionality and making sure that future updates do not regress the controls behavior is useful.

On another note it may be useful to considering other rendering engines than Skia. Vello for example seems really fast and it uses wgpu for rendering so it should work on even more platforms than Skia. Using wgpu for headless rendering and then putting the result into the Skia pipeline could be fast if it can be done within the GPU.

Although most of that would be premature. The first release should be something that can display and edit simple rich text.

[alexandrehtrb]

To be honest, I just need a TextBox that can show coloured parts of text