Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] SKTypeface.GetGlyphs has changed meaning in v2.80 #1398

Closed
mattleibow opened this issue Jul 13, 2020 · 0 comments · Fixed by #1399
Closed

[BUG] SKTypeface.GetGlyphs has changed meaning in v2.80 #1398

mattleibow opened this issue Jul 13, 2020 · 0 comments · Fixed by #1399
Milestone

Comments

@mattleibow
Copy link
Contributor

mattleibow commented Jul 13, 2020

Description

Previously, calling SKTypeface.GetGlyphs(...) would basically cast the incoming pointer to the type specified by the encoding. So, for a UTF32 encoding, it took the pointer and cast to uint32_t*. The new way is to "convert" to UTF32.

This is a breaking change and needs to be fixed.

Old: https://github.com/mono/skia/blob/v1.68.3/src/ports/SkFontHost_win.cpp#L2044
New: https://github.com/mono/skia/blob/v2.80.0/src/ports/SkFontHost_win.cpp#L1897

What actually happened under the hood was that the typeface handed all encodings. However, in v2, this was changed and only handles UTF32, so I redirected the logic to SKFont which does the conversion. This was incorrect.

Code

See code in: toptensoftware/RichTextKit#15

Expected Behavior

GetGlyphs(int*, Utf32) should not convert the data to UTF32.

Actual Behavior

Conversion.

Basic Information

  • Version with issue: 2.80
  • Last known good version: 1.68.3

Screenshots

N/A

Reproduction Link

toptensoftware/RichTextKit#15

@mattleibow mattleibow added this to the v2.80.1 milestone Jul 14, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Aug 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant