Fixes for TextLeadingPrefixCharacterEllipsis

[ppaszkiewiczcom]

What does the pull request do?

TextLeadingPrefixCharacterEllipsis can now correctly handle multiple TextRuns.

This is a followup for #17998
And fix for #19339

What is the current behavior?

Current implementation of TextLeadingPrefixCharacterEllipsis only works when TextLine has a single ShapedTextRun.

When there's more (there are emojis or special characters) it breaks by crashing (in debug mode) or incorrectly accumulates availableWidth which ends up excessively trimming the text (in some cases only leaving the ellipsis).

This affects TextTrimming="LeadingCharacterEllipsis" and TextTrimming="PrefixCharacterEllipsis":

What is the updated/expected behavior with this PR?

TextLeadingPrefixCharacterEllipsis should now correctly measure the text and prepare the prefix:

How was the solution implemented (if it's not obvious)?

Update TextLeadingPrefixCharacterEllipsis.Collapse logic.

Checklist

• Added unit tests (if possible)?

Known issue:

PrefixCharacterEllipsis has inconsistent results with RTL text (ie. hebrew characters)

• TextFormatterImpl.SplitTextRuns return value might not be correct
• bidi level of default ellipsis (…) is lower than rest of text which can cause unexpected reordering of prefix

Fixed issues

Fixes #19339

[avaloniaui-bot]

You can test this PR using the following package version. 12.0.999-cibuild0058024-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[cla-avalonia]

• All contributors have signed the CLA.

[ppaszkiewiczcom]

@cla-avalonia agree

[Gillibald]

We should probably inherit the bidi level from the split run, so nothing changes.

Could you clarify when TextFormatterImpl.SplitTextRuns produces wrong results?

[avaloniaui-bot]

You can test this PR using the following package version. 12.0.999-cibuild0058621-alpha. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

[ppaszkiewiczcom]

There might be an issue when provided text runs have mixed bidi-levels. But I'm not 100% certain because I don't entirely comprehend how mixed bidi-level text is supposed to come out.

Also tried with forced RTL ellipsis (TextFormatter.CreateSymbol(Symbol, FlowDirection.RightToLeft)) but the result gets even more confusing to me

[Gillibald]

I think the text trimming implementation needs to be rewritten so it uses the hit testing APIs to find the actual split positions.

We need to find the run that is at the split position and remove glyphs from it until the line fits into the requested width. This is a single position for trailing or leading ellipses and two positions for trimming with a defined prefix/suffix.

In the end, the algorithm should not change the bidi order, etc.

[AuroraZiling]

We faced the same exceptions in #18267, and this PR could fix it.

BTW, I tested the similar issue #20535, the PR could also work fine.

[ppaszkiewiczcom]

This PR works perfectly fine but only when text is entirely Left To Right.

I don't have the know-how or time to fix the RTL and mixed BIDI level issues.
So if someone is more knowledgeable about it feel free to clone/takeover this solution.

[0x90d]

This fixes a bug I reported in #20535, but it reveals another issue with /emoji-🎬-video.mkv, which then triggers an InvalidOperationException: Cannot split: requested length 1 consumes entire run in TextFormatterImpl.SplitTextRuns. However, this is a pre-existing, latent bug and not a regression. Can we please merge this PR? Many months have passed, and even though it may not be perfect and some things could be done differently, nothing at all has happened, and the text formatting is still completely broken. It would be better to fix this first, and THEN we can think about what else should be done to improve or redesign it.

[Gillibald]

Should be fixed in master