openfl
openfl copied to clipboard
UTF16 broken on Mac still
Related to #2300 and company. It seems like Unicode characters on Mac don't work on latest, and the resolution for Windows/Linux/etc doesn't seem to fix it.
Needs more investigation, as I cannot test on Mac to play around with it. I would also be concerned about iOS, since that one was never confirmed either.
(This is the addUTF16
ifdefs within TextLayout)
I have a same problem.
Couple ideas:
- Add a haxedef for
HX_SMART_STRINGS
- Add a condition for
mac
that usesaddUTF32
instead ofaddUTF16
(same parameters) - Try
addCodepoints
(same parameters) - ~~Add
mac
to the HL condition~~ this one doesn't work - Put a trace inside
addUTF16
to see if the supplied pointer is actually pointing to something (ie nonzero) - Instead of
text.wc_str()
, trytext_wchar_str()
- ~~get a PC~~
As best I can tell, the final #else
with addUTF16()
works correctly on macOS, so only Neko and HL will need special cases.
I confirmed that the following example from #2264 was fixed after this small change (in commit f8301ce):
var _body:TextField = new TextField();
addChild(_body);
_body.text = 'фыва йцук';
It no longer renders "DK29F".
macOS Monterey 12.1 Haxe 4.2.4 OpenFL commit f8301ce Lime 7.9.0