Before talking about the thought that I should make multilingual input a reality, it seems right to first tell the story of implementing Korean. That is because realizing that what had first looked impossible for me was only one gateway made me want to try things beyond Korean as well. If implementing only Korean and English input had taken weeks of time and more than an hour or two of effort each day, as I had first imagined, I would not have dared to dream of anything beyond that. There is a great difference between thinking, even if it is hard, “This is doable,” and merely wishing that I had the environment or talent to make it doable. It creates the difference between whether one begins or not, a situation of either 0 or 100.
If there is an operating system like Windows, macOS, or Linux, one can simply use the language packs provided by that operating system. That is why it did not take so much time on the Raspberry Pi-based Ize Ribbon. But in firmware that had to be built up from the beginning, the environment was a little different. I did not know that at the time, but I learned it one step at a time.
First, I did not know how keyboard input was applied in the code. I had to test it. Second, there was no font. Third, in Korean, the character code differs depending on whether a syllable has a final consonant.
These were all gateways I came to know only after making firmware. Before that, I thought every language already had something like a common language pack, and that I would only have to choose Korean as one does in Windows or macOS. I thought that if I simply pressed a key on the keyboard, the character would appear on its own. It was also then that I first learned that I had to match the signal coming from the keyboard with the character, one by one. At the time, I was simply following Gemini’s instructions, doing what it said should be done this way or that way, like back in my university days when I looked at an embedded Linux book and blindly typed commands without knowing what they meant. So even as I was putting things in, I thought, “I have to go through all these steps? This feels like making the whole thing from scratch.”
And really, that was what I was doing. I was making it from scratch.
What surprised me most was the scope of that “from scratch.” According to Gemini, putting in ASCII codes was not difficult, but the screen could not display them because it did not know the shapes of the characters. Does that make sense? Until then, I had thought that when letters were entered into a computer through a keyboard, the computer displayed those letters. But even if I entered the character code, I had to tell it what that code was supposed to look like. If I entered “giyeok,” I had to tell it that the shape was “ㄱ.” I had to tell it all of that for more than ten thousand characters.
“Then do it. Am I going to do that myself? Gemini will.”
That was the thought I started with. What I was thinking at the time was that instead of putting in every character shape according to each character code, I would only put in the Korean jamo and have the screen display them gathered together, like a typewriter. If it had displayed them that way, it probably would have looked truly typewriter-like, with a separate line left for final consonants. But Gemini said most Hangul automata were already known on the internet, and that the process of combining codes - in other words, how “ㄱ” and “ㅏ” meet to make “가” - was already easy to implement. To be honest, I did not understand what it meant, but since it said it was possible, I simply proceeded in that direction.
In other areas, if something did not work, I would go around it, try again, or, if that too failed, give up by calling it an AI limitation and think up a new idea myself. But for Korean, I told Gemini to do whatever it wanted, and I think it was completed in about four hours. I started after work and finished before going to bed that night.
I checked that pressing Shift produced “ㄲ” and “ㅉ” and the like, but I also saw that letters without double-consonant versions would not input at all while Shift was held down. When Caps Lock was on, only double consonants were typed. When Caps Lock was on and I pressed number keys, symbols such as $ and % appeared, so I made Caps Lock ignored, only to see that even when I pressed Shift, the special characters above the number keys no longer entered.
For the rest of the weekend, I continued this kind of debugging that was not quite debugging. Since the program was not crashing or producing errors, it may not have been the kind of thing properly called debugging. Still, if the device behaved differently from what one expected while writing, then it was something that had to be fixed.
Because I wanted the writing to begin from the bottom line, I asked it not to start at the top, but to calculate the area of the screen, the height of one line of text, and the space between lines and letters, and then move the starting point down to the bottom line. This may have been the biggest threshold. The hardships that came later were real hardships, but this was simply the threshold of whether I would keep going or not. Since the code that wrote from the top was backed up anyway, I could have stopped there and simply used it. But the feeling that it was almost working, yet not quite, made me spend the whole weekend clinging to it.
In fact, the Hangul composition work itself was all finished there. The function that composed Hangul, receiving “ㄱ,” “ㅏ,” and “ㄱ,” and then, if the next input was a space or a consonant, replacing them with the syllable “각” and discarding the old input, was working normally. Now the problem was maintaining the characters that had been made that way. More than the internal operation itself, what the user saw on the screen had become more important. No matter how correctly the internal computation proceeded, the fact that even one character was not visible had become the more important issue.
Korean original: 한글 활자 만들기