Font Problem on Mac OS X

Hi, I have recently built an application for an info terminal with OpenFL and Haxe. It works fine in the HTML 5-Version. Now I have tried to build a Mac OS apllication and it seems to me that the font embedding does not work. Parts of the font are displayed correctly but there seems to be a problem with the German „umlauts“ ÄäÖöÜü. The sentence …

Bitte wählen Sie das gewünschte Thema aus.

e.g. looks like this …

Bitte whlSie das gewnsThema aus.

There are not only single letters missing but whole parts of the words. Does anyone have an idea how to solve the issue or where I can look for a solution? The font is OK, I think, because it is not just one font with this problem. Is this maybe a known issue?

Thanks for help, Christof

You need to set a font for the textfield:

var _font = new TextFormat("fontName.ttf");
_display.setTextFormat(_font);
1 Like

Thanks. But I already do that. And as I said it works fine in the HTML5-Version. Just in the Mac-Version the problem occurs. The font is at least partly embedded and looks as it should exept from the error described above.

1 Like

It is almost impossible that it is a font issue. More likely, you are having a unicode encoding issue, where you are trying to draw a UTF8 string when it needs UTF16. Remember that JS/Flash use UTF16 internally not UTF8, and you will get garbled results if you use the wrong string format. If you do believe it is an actual font problem, then peek into the font and see.

This may be a hot trace! Thanks for the hint and sorry for the late response. I will try out to look after that on the weekend.

Hi,
I am on Mac,I have the same problem. I choose cpp as target, but it doesn’t accept accents.
This is a problem that I have been trying to solve for the past few days, but none of the solutions that I have explored are working.
How do we display accents and glyphs on cpp ?
Thanks.
(Sorry for my English)

Recently had the same problem while targeting mac and ios.
Like CodingFiend said, it’s an encoding issue.
What did the trick for me was changing line 143 from #if (neko || mac) to #if (neko):

1 Like

I thank you for your answer. I had already tried this solution on an older version of openfl, but was unsuccessful. The latest version incorporates this correction. Still without success. Otherwise for Neko, there are no more crashes when there are two spaces, on the other hand the expression substring () no longer allows to display special characters.

Sorry, I forgot to mention that my problem was also regarding “umlauts”, not accents.
Still had to make this change in the current version 9.1.0 to make sure that

__hbBuffer.addUTF16(untyped cpp(’(uintptr_t){0}’, text.wc_str()), text.length, 0, -1);

will be executed instead of

__hbBuffer.addUTF8(text, 0, -1);

for the mac target. Also tested it with accents and it seems to work (haxe 4.2.1., openfl 9.1.0, lime 7.9.0).

accents

Excuse me for not having correctly interpreted your first indication. I just made this modification
and now it works perfectly.
Thank you so much. :grinning:
(The horizon is revealed again)

Nice! Happy to help removing some clouds. :grinning:

Many great thanks, especially to Beckwahn! Now it works!

1 Like

@Beckwahn I implemented your fix and it solved the encoding problem for me. Do you think the “mac” case should be removed altogether from upstream?

I’m not sure if it could cause any problems, but I’d be happy to create a pull request for this issue.

I’m not sure either. Would be great to hear from the person who implemented it, if there’s still a reason for UTF8 encoding on the mac…?
On the other hand, I didn’t have any issues in the past months that seemed to be related to this quick fix.

1 Like