Hacker News new | past | comments | ask | show | jobs | submit login

> Video game engines absolutely handle text rendering across a wide range of languages.

They handle specific subsets of text rendering across a wide range of languages. There's a ton of interactions with the OS-level text interactions that are both difficult to fully enumerate and even more difficult to re-implement non-natively. Font programming can get really, really complex—some of it might be perceived as unnecessary—ligatures, proper kerning, certainly sub pixel rendering, glyph variants, arguably emoji—but others will really suck, like poor interactions with highlighting and cursor movement; replicating native keybindings; replicating differences in how e.g. linux and Macs kill, yank, copy, cut, paste, etc; replicating differences in how "paragraphs" are split into "lines" (logical or visual?) across platforms.... this isn't even touching the complexity of processing input (do you really want to implement wubi chinese? Do you know how to properly handle unicode normalization the same way the local editor does so that typing the same keystrokes causes the same behavior? how about differences between punctuation glyphs between scripts? Are you even handling hyphenation correctly? Does it reflow as expected when the layout constraints change?) and simply processing unicode in a consistent and well-behaved manner.

(and of course this isn't even touching attributed text or rich text editing or combining fonts on a single line....)

> Accessibility is often language in game technology

I'm no expert, but accessibility concerns must be wildly different in a game than in a data-heavy or prose-heavy app. I can't imagine implementing a screen reader without relying heavily on the OS....




> They handle specific subsets of text rendering across a wide range of languages.

People radically overstate how hard this is. Yes there’s a lot of cases. But God bless UTF-8 which provides a very clear path.

There are countless hobby text editors and libraries that handle literally all of this.

> I can't imagine implementing a screen reader without relying heavily on the OS....

Of course. You “just” need to use the documented OS APIs. It’s not trivial. But like it’s not that hard to use the APIs that lots of programs and libraries already use.


> There are countless hobby text editors and libraries that handle literally all of this.

The thing is, there really aren't. Certainly not that I would characterize as a "hobby" text editor.


> But God bless UTF-8 which provides a very clear path.

It's a very clear middle finger for CJK users if text rendering issues were dismissed because "we do UTF-8." Thanks to the Unicode Consortium, letters from CJK languages have shared code points in Unicode. This makes it very easy to have, for example, Chinese style fonts sprinkled over Japanese text. This kind of mixed styles are aesthetically inconsistent, unpleasant, and hard to read.

https://en.wikipedia.org/wiki/Han_unification

i18n is very much not about slapping on UTF-8 support and calling it a day.


> i18n is very much not about slapping on UTF-8 support and calling it a day.

Every major game engine has robust support for internationalization. It’s a strict requirement for professional video games.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: