drawTextInRect bugs(?)

[Tengu]

Windows, Lua, SDK 2.6.1

Any idea what's going wrong? This stuff used to work, it doesn't now.

[Tengu]

The only thing I can think of is that there have been changes to drawTextInRect recently (moving the impl from Lua to C?).

Here's the text string that used to render fine, and the font:

"ハーブ を もって きて ください。けんこう ポーション を つくって あげます。 \n\nうって、ざいりょう を あげましょう。"

utt-font.zip (10.4 KB)

[Tengu]

This glyph (う) is rendering as two question mark thingies. It's in the font file (.fnt) ok as far as I can tell. It used to work.

Edit: if this glyph is broken (due either to the glyph itself or some SDK string/font parsing error) there are likely other glyph/situations that are broken also. I shudder at trying to find them all (UTT is large).

[omoikane]

I suspect the font is OK because the u in "うって" rendered properly. One possible experiment to try is to replace the うin those troubled spots with some other character and see what happens.

[Tengu]

I've been poking at it... it's not a problem with the font, I think it's in the SDK UTF8 string parsing. The glyph in green above is good. The one in red is good now, but was bad a second ago.... What changed is I put a space in front of 'う' glyph for the red one.

It looks like a multi-byte processing issue, the SDK code is getting confused.

[Tengu]

Yes, this is broken... the text:

"ほうせき、ルーン もじ、ベラム、ハーブ を もって きて くれ。まきもの を つくって あげる から。\n\nそれら を うって くれ。"

Won't render the (ー) glyph properly unless I add a space in front of it (before/after):

[Tengu]

As eltee pointed out offline:

that is dangerous cause it probably means its going to have overflow errors now if they aren't handling the sizing of characters/strings properly

[Tengu]

Someone on the Playdate Squad discord pointed out that the issue seems to be related to word wrap... sounds like a clue for Panic .

[Tengu]

Test case attached:

a_rect_bug.zip (37.6 KB)

[dave (Dave Hayden)]

Here's the version of CoreLibs/graphics.lua we'll be shipping in the next update to fix this problem: graphics.lua.zip (4.4 KB)

The previous wasn't utf-8 aware, would try and wrap in the middle of utf-8 sequences. You might notice that in 2.5 when it wrapped it would drop characters that the line wrapping function split. In 2.6 we added line wrapping to the core drawText function and also simplified the utf-8 parser. (The new code leaves the split, invalid utf-8 sequences intact instead of ignoring them, which is where those box glyphs are coming from.) drawText() is a lot faster than the CoreLibs version, so if text drawing is a bottleneck in your code try that instead!