Hi Casey!

First of all, congratz on the show, it's just excellent! :-)

Regarding font rendering: during yesterday's show, someone in the the Q&A asked whether the asset system/renderer could support fonts for languages that are written right-to-left, and that indeed seems to be the case. However, I was wondering if/how it could support more complex languages where the choice of glyph is context sensitive, like in arabic, where the glyph for a given character is different depending on whether a character is at the beginning/end/middle of a word? or in other languages where when you put two letters consecutively in a word, they collapse into a single glyph

You can take a look at http://scripts.sil.org/cms/script...item_id=CmplxRndExamples#07420d33 for some more examples.

Cheers from Belgium! :-)

-Cédric

I don't believe that actually requires any changes to the font system. That's more about parsing the characters. Although really you don't even have to do that, because you could just choose to store the text for the game _pre converted_, couldn't you? Eg., the right glyph choice is just baked into the strings you're displaying for that language?

- Casey

In English, the glyph can be different if it's the first letter of the first word of a sentence. How is this conceptually any different?

cmuratori
I don't believe that actually requires any changes to the font system. That's more about parsing the characters. Although really you don't even have to do that, because you could just choose to store the text for the game _pre converted_, couldn't you? Eg., the right glyph choice is just baked into the strings you're displaying for that language?

- Casey

For Arabic, yes, because the variant forms have their own codepoints.

However, some scripts have combining forms that don't have codepoints for precomposed glyphs. https://en.wikipedia.org/wiki/Complex_text_layout

One possible option is just to prebake entire strings and let Windows sort it out. Since full Unicode is only really necessary for UI, there's probably some finite set of strings that would be needed for any given language.

EDIT:
Of course, the market for games in Thai may or may not be large enough to justify the extra effort and complexity.

Even though it's not strictly Handmade, I wouldn't have a problem with Casey incorporating something like ICU in the asset packer if it turns out to be useful.

Or Uniscribe if we are using Windows API for rendering fonts. Here's a nice tutorial on it: http://www.catch22.net/tuts/introduction-uniscribe

But I don't think this can be solved on asset packer level. Because it renders only individual characters. You need this information when you are putting individual glyphs together at runtime.

And anyway - this is for debug text only. For Handmade Hero it would be perfectly fine to use monospace fonts in 32..127 range only. No need for kerning, no need for unicode at all.

mmozeiko
But I don't think this can be solved on asset packer level.

Strings are assets too.

What if your game allows text chat between players online? You can not possible store every single word in every language in assets.

Not every word, rather every special combination of characters that yield different glyphs.