Testing "None" is not great. Can you at least verify that the fix resolves your issue?

Does this not make RTF contain links that do not work until XAML-unescaped, breaking them for any other applications reading the RTF?

Testing "None" is not great. Can you at least verify that the fix resolves your issue?

That does not seem especially constructive. It should be possible to embrace the investigations and efforts of the wider community in addressing low priority issues which no-one else here has shown any interest (this issue, sample repro, and work around were clearly described over 2 years ago).

That said, a small test project examining the effect of reversing the application of XamlParserHelper.AppendRTFText and BamlResourceContentUtil.UnescapeString verifies the problem with the current implementation and that this is an appropiate fix.

Take a valid, but pathological FlowDocument containing a Hyperlink with NavigateUri https://www.github.com/dotnet/wpf/&ö.

The FlowDocument containing such a NavigateUri stores the value as https://www.github.com/dotnet/wpf/&ö.

When converting that XAML to RTF (unicode), the current code first uses XamlParserHelper.AppendRTFText to give https://www.github.com/dotnet/wpf/&\u246 and then BamlResourceContentUtil.UnescapeString to give https://www.github.com/dotnet/wpf/&u246. Converting the same XAML to RTF (CP1252) gives https://www.github.com/dotnet/wpf/&'f6. Neither is a correct representation of the original Uri (data corruption) and the second cannot be converted back to XAML in WPF (exception when decoding).

With the PR, BamlResourceContentUtil.UnescapeString is used first to give https://www.github.com/dotnet/wpf/&ö and then XamlParserHelper.AppendRTFText gives https://www.github.com/dotnet/wpf/&\u246 for Unicode or https://www.github.com/dotnet/wpf/&\'f6 for CP1252, both of which are valid RTF representations of the original Uri.

This is an obvious and trivial error in the original implementation. To ensure clean conversion, escapes in one format must be removed before attempting to escape in another, especially in cases where there are overlaps in characters involved in escape sequences (i.e. \).

Does this not make RTF contain links that do not work until XAML-unescaped, breaking them for any other applications reading the RTF?

Obviously not. In both the orignal and PR, the XAML escapes are clearly removed. It is the order in which they are removed which matters. This PR ensures XAML escapes are removed to obtain the logical string prior to conversion to valid RTF representation.

That does not seem especially constructive.

Asking the PR author try to 1) make sure the change compiles 2) ensures it fixes the problem for them is not only a reasonable expectation and a clear constructive suggestion to do, but it also ensures author's issue is resolved to their satisfaction if the PR is merged and saves everybody's time.

Either way, it is one of the pull requests acceptance critera.