Eto: 在不打扰 RichTextArea 的情况下构造 RTF 字符串

嘿@katatunix ，感谢您的请求。 我实际上一直在研究这些方面的东西（各种 TextBuffer），它具有与 RichTextArea 完全相同的 api，但允许您单独构建它，然后将其附加（或设置）到 RichTextArea。

我希望它做的一件事是让它可以在后台线程中构建，但不幸的是，并非所有平台都支持这一点。 不过我还在调查这个。

如果你有这方面的任何代码，我想看看它。

@LaraSQP我刚刚在 PR #1507 中上传了我的作品

既然RichTextArea控件只处理几个属性（字体+样式，前景色+背景色），为什么不写一个“简单”的rtf类来组成一个rtf字符串，然后把它提供给RichTextArea.Rtf财产？

就像是：

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

我是不是在这里错过了一些东西并再次成为一个白痴？

@LaraSQP不，那完全有效。 不过 GTK 不支持 RTF。

我不认为 Eto 需要直接提供该功能，因为您没有理由不能使用外部 RTF 构建器然后将其提供给 Eto 的控制。

不知道 GTK 和 RTF。 那真是太糟糕了。

由于原始海报带来的问题（与 Eto 相比，不同的类/类型，例如字体、颜色……），外部 RTF 构建器将无法正常工作，并且在任何情况下，RTF 流都需要是转换为 GTK 可显示的东西。 因此，您的TextBuffer 。

该死的

@LaraSQP你

然而，RTF 的问题在于，尽管它是“标准”，但它的组成确实因平台而异（至少 Mac 与 Windows）。 特别是 RTF 中指定的字体名称非常不同。 您可以在 Mac 上使用 TextEdit 与在 Windows 上使用 WordPad 来查看差异。

希望这可以帮助。

确实很乱。

必须说你在 Linux 移植方面做得很好。 尽管大量使用多种字体和颜色，但几乎没有任何性能损失。

尽管 Windows 上的相同代码是一个 slug。

尽管 Windows 上的相同代码是一个 slug。

是的，不知道如何解决这个问题.. FlowDocument 非常慢。

既然在 Linux 上的表现非常出色，你知道它在 Mac 上的表现吗？

@LaraSQP它在 macOS 上也应该很快。 根据我的经验，目前只是 WPF 速度很慢。 我想找到一种方法来让它更快（;

在这种情况下，请考虑对我关闭此问题。