Questions about bracket-term unicode mode.

[km19809]

Hello. I am interested in RLTK recently. As a Korean, I want to make the Korean language support. So I tried to print Hangul(Korean characters) to the console. But 'main' has panicked. I managed to find that the PNG font file caused the panic. There is no combined hangul at all.

So, here's questions:

1. How can I append this font file? I have some pixelated Hangul fonts that fit 16x16 size, but I do not know how this PNG file was made. Let me know how you build this image, please?
2. It panicked at hal\gl_common\backing\simple_console_backing.rs:119:21 It panicked due to as, and the message was not much helpful. (thread 'main' panicked at 'attempt to subtract with overflow') How about using TryFrom or TryInto with expect?

Thank you.

[thebracket]

The unicode support is pretty bad right now. It was hacked together to help jojolepro, and never really cleaned up.

The "unicode" PNG is 2048 x 4096 in size (which is why it takes so long to load in debug mode). Each character is 16x16, so there's 128 characters per row and 256 rows.

With that information, we can throw together a quick Rust program to show where on the font-sheet you should put characters:

fn main() {
    let output = "ABC";
    let indices : Vec<(u16,u16)> = output.chars()
        .map(|c| c as u16)
        .map(|c| (c % 128, c / 128))
        .collect();
    println!("{} = {:?}", output, indices);
}

Running it with "ABC" yields: ABC = [(65, 0), (66, 0), (67, 0)] - they should start in position 65 on the 1st row. That looks about right.

Trying with another example from the unicode example, shows us: 真棒 = [(31, 238), (82, 209)]. Looking at the image, that also looks about right.

Hopefully, Google Translate can be trusted to turn "Hello World" into Korean: 헬로월드 (My apologies if that's not what Google says it is!). So running the program with that input yields:

헬로월드 = [(108, 427), (92, 368), (84, 397), (92, 361)]

So you'd expect to find the first character (헬) at column 108, row 427. With the current encoding, you'd expect to find it at pixel position x=1,728 y=6,832. That's going to require a really big font file. (You could mitigate it a lot by using solid black for everything else; PNG compression would eliminate most of the overhead).

I'll mark this as an enhancement for a future version. I'd like to go and see how Dear Imgui handles it; it lets you specify code-page ranges and map them more sensibly.