Fix conversion of FlowDocument to RTF where the source contains NavigateUri with non-ASCII characters

[elyoh]

Fixes #7601.

Description

Saving the content of a FlowDocument to Rich Text Format (RTF) leads to malformed RTF if the source XAML contains a NavigateUri with non-ASCII characters. This PR addresses the issue by correcting the conversion sequence to remove any XAML escape sequences from the NavigateUri value first, thus obtaining plain text which can be correctly escaped for RTF.

Customer Impact

Conversion between FlowDocument and RTF correctly handles Uri values containing non-ASCII characters without data corruption.

Regression

No.

Testing

None.
FixValidation.zip

Risk

Low. Two existing steps in the conversion have been applied in the correct order.

Microsoft Reviewers: Open in CodeFlow

[miloush]

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

[miloush]

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

[elyoh]

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.

[miloush]

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.