Do not treat combining marks as whitespace #19498
Conversation
Gillibald
changed the title
Gillibald
added
bug
backport-candidate-11.3.x
Try to find a matching typeface on a grapheme boundary
Gillibald
changed the title
|
Does it mean a combining mark present in one font will be able to properly combine with a base letter in another font? Think I had a problem with this in the past. |
|
You can test this PR using the following package version. |
No. A combining mark is usually positioned in combination with a base character. So you always want to share the same font. If there is no base character, the combining mark can be rendered with a different font. |
Gillibald
changed the title
|
You can test this PR using the following package version. |
Gillibald
changed the title
|
You can test this PR using the following package version. |
Gillibald
changed the title
* Do not treat spacing combining marks as whitespace * Do not treat combining marks as whitespace Try to find a matching typeface on a grapheme boundary * Add embedded font for testing * Remove using * Fix naming and remove redundant code * Apply default until we reach the next base character
Gillibald
added
backported-11.3.x
and removed
backport-candidate-11.3.x
|
Relevant: dotnet/wpf#6857 |
5 participants
What does the pull request do?
This PR removes the combining mark category from the list of categories that are treated as whitespace. Therefore, combining marks are now used to find a matching font and are properly displayed if no other base character is present.
This also changes the font matching logic so it tries to find a match on a grapheme boundary instead of a codepoint boundary. This makes the IsWhitespace check redundant and we solely rely on graphemes.
What is the current behavior?
What is the updated/expected behavior with this PR?
How was the solution implemented (if it's not obvious)?
Checklist
Breaking changes
Obsoletions / Deprecations
Fixed issues