feat(Run): [Skia] Add Unicode Symbol and Emoji support

[workgroupengineering]

GitHub Issue (If applicable): closes #

PR Type

What kind of change does this PR introduce?

• Feature

What is the current behavior?

What is the new behavior?

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Docs have been added/updated which fit documentation template (for bug fixes / features)
• [ ] Unit Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
• [x] Validated PR Screenshots Compare Test Run results.
• [x] Contains NO breaking changes
• [ ] Associated with an issue (GitHub or internal) and uses the automatic close keywords.
• [x] Commits must be following the Conventional Commits specification.

Other information

Internal Issue (If applicable):

Before

After

[gitpod-io[bot]]

[jeromelaban]

Very nice! I'm currently some basic screenshot testing based on your work on RenderTargetBitmap in https://github.com/unoplatform/uno/pull/9439. You should be able to include some regression testing with it.

[workgroupengineering]

Very nice! I'm currently some basic screenshot testing based on your work on RenderTargetBitmap in #9439. You should be able to include some regression testing with it.

Sure, I will do this after you merge #9439

[workgroupengineering]

@mikernet Can you review? Please.

[mikernet]

@workgroupengineering Interesting approach, I like some aspects of this more than the fallback font approach I was taking as I was working on this as well. I believe this also handles the international char segment case as well, but there are a couple issues:

• As far as I can tell, it will attempt to call MatchCharacter for every codepoint that composes of a surrogate pair and create a new segment for it with a word-break-after opportunity. Not every codepoint composed of a surrogate pair has a word-break opportunity after it and calling MatchCharacter for every single international/emoji char and creating a separate Run and Segment for it is a performance issue.
• Setting the inline associated with a segment with a separate detached Run instance that isn't actually part of the document tree is going to break hit testing, i.e. hyperlink hit testing, the TextBox work I'm doing now and future TextBlock selection / rich edit controls support, since we can no longer walk the parent tree of the inline: https://github.com/unoplatform/uno/blob/5502f733ca2b8fae8a2f363440b763001afab498/src/Uno.UI/UI/Xaml/Controls/TextBlock/TextBlock.skia.cs#L53-L74

For the first issue, the solution is to just shape the buffer presuming that it will work, then check if all the characters matched with a glyph. If so then you can just add a single segment. If not then you call MatchCharacter on the first non-matched glyph and then try to shape all the missing glyphs again with that font again, so a segment that contains a long string of international chars (for example) would only require a single MatchCharacter call, and then you only need to add one segment for each set of consecutive chars that use the same font.

For the inline detached Run instance issue: instead of creating another Run, the Segment can just keep a nullable reference to a fallback font. When rendering/measuring the InlinesCollection it can check if the segment has a fallback font set on it and it can use that instead of the font associated with the Inline.

I have all the above done already so I think it will be easiest if I take the good parts of this and merge them into my implementation. I just prioritized the TextBox work in the last week so I shelved finishing the fallback font support until that was done.

[MartinZikmund]

/azp run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 2 pipeline(s).