Eto: RichTextAreaを気にせずにRTF文字列を作成します

ねえ@katatunix 、リクエストありがとう

私がやりたいことの1つは、バックグラウンドスレッドで構築できるようにすることですが、残念ながら、すべてのプラットフォームがこれをサポートするわけではありません。 私はまだこれを調査しています。

これに関するコードがあれば、私はそれを見てみたいと思います。

@LaraSQPこれまでの作品をPR＃1507にアップロードしました

RichTextAreaコントロールはいくつかのプロパティ（フォント+スタイル、前面+背面の色）しか処理しないため、「単純な」rtfクラスを記述してrtf文字列を作成し、それをRichTextArea.Rtfフィードしてみませんか。

何かのようなもの：

https://www.codeproject.com/Articles/30902/RichText-Builder-StringBuilder-for-RTF

私はここで何かが足りなくて、またバカとして出くわしているのでしょうか？

@LaraSQPいいえ、それは完全に機能します。 ただし、GTKはRTFをサポートしていません。

外部のRTFビルダーを使用してEtoのコントロールにフィードできない理由はないため、Etoがその機能を直接提供する必要はないと思います。

GTKとRTFについて知りませんでした。 それは残念です。

元のポスターによって引き起こされた問題（Etoとは異なるクラス/タイプ（フォント、色など））のため、外部RTFビルダーはそのままでは機能しません。いずれの場合も、RTFストリームは次のようにする必要があります。 GTKで表示可能なものに変換されます。 したがって、 TextBuffer 。

ダーン

@LaraSQP理論的には、外部ツール/ APIを使用してRTFを構築し、それをEtoにロードすることができます。 Etoのフォント/カラーを使用して、本当に必要な場合はそれらをRTF対応の形式に変換できます。

ただし、RTFの問題は、「標準」であるにもかかわらず、プラットフォーム（少なくともMacとWindows）によって実際には構成が異なることです。 特にRTFで指定されているフォント名は大きく異なります。 MacのテキストエディットとWindowsのワードパッドを使用した場合の違いを確認できます。

お役に立てれば。

確かに厄介です。

Linuxポートで素晴らしい仕事をしたと言わなければなりません。 複数のフォントと色を多用しているにもかかわらず、パフォーマンスの低下はほとんどありません。

ただし、Windowsの同じコードはスラッグです。

ただし、Windowsの同じコードはスラッグです。

ええ、それを回避する方法がわかりません..FlowDocumentは非常に遅いです。

Linuxでのパフォーマンスは優れているので、Macでのパフォーマンスを知っていますか？

@LaraSQPそれはmacOSでもかなり速いはずです。 私の経験では、現時点でかなり遅いのはWPFだけです。 私はそれをより速くする方法を見つけたいのですが（;

その場合、この問題は解決されたと考えてください。