We all know that text encoding in LFS is a bit peculiar, as it relies on the very old CP1252 code pages system from the 90s. Scawen himself is aware of this, and has said a few times (even back then in ~2005) that Unicode would probably be the way to go to support more languages. Now in 2025, LFS is still using code pages, and has even expanded their use to support more languages, such as Chinese, Japanese, and Korean, among others. I believe this happened because it was the easiest way to add support for those languages at the time; while Unicode should be the better solution, implementing it may require an enormous amount of work, and there are definitely other priorities right now.
Still, those code pages bring a few issues with them:
-----
Anyway, this is not another "please add Unicode support" thread (although I do want to see Unicode support
), I just made this thread as a recap of sorts of the current situation, and to add an interesting issue I found just yesterday while experimenting with InSim buttons to try and draw road signs.
Take a speed limit sign for example (Europe style): the sign is circular, with a white background, a red border, and black text stating the speed limit. We should be able to draw such a sign using 3 IS_BTN packets. LFS even supports the characters we want to use for that: ● for the background, ○ for the border, and digits for the text (for better control over border thickness, and due to general quality of large text rendering, I ended up using ● for the border as well, resizing the button appropriately). My understanding of InSim button z-order, through earlier testing, has been that buttons with a lower clickID are rendered first, and therefore buttons with a higher clickID appear on top. This is generally true... but not always!
Trying to render my speed limit sign, the text is nowhere to be seen, but if I add more text so it spills out of the sign, I can see it being rendered behind the sign, despite having a higher clickID (in the above example, the text reads "505050"). It would appear that characters from different code pages do not follow the clickID z-order, which becomes a headache when dealing with buttons. (for the record, in the above example, the border button has ID 0, the background button has ID 1, and the text button has ID 2)
Even better, this also applies to characters in a single button: in the following example, I created 2 buttons, same position, same size, with texts "^0●a" and "^7b", and here's what the result looks like:
We only have 2 buttons here, but the "b" character appears both in front and behind characters from the other button, simply because they're from different code pages!
It would be nice to get more info about the rendering logic, or whether this can be fixed for consistency, as it unfortunately makes it impossible to draw those signs, or any other kind of button combination that would rely on characters from different code pages (in this example, ● is converted to a Japanese code page character as [94, 74, 129, 156]).
Still, those code pages bring a few issues with them:
- Limited language support, as only the available code pages are supported, and I doubt there even exist enough code pages to support most languages.
- Limited character support: I don't think supporting emoji is a goal here, but there are still many unsupported Unicode characters (basically anything not in the code pages).
- InSim libraries have to implement a UTF-8 to LFS (and LFS to UTF-8) conversion, as the entire world uses Unicode today ("As of July 2025, UTF-8 is used by 98.7% of surveyed web sites.").
- For LFS itself, while they still work, they do represent a huge technical debt, where using UTF-8 should make things easier, but changing code pages to UTF-8 is becoming more and more difficult and time consuming.
-----
Anyway, this is not another "please add Unicode support" thread (although I do want to see Unicode support
), I just made this thread as a recap of sorts of the current situation, and to add an interesting issue I found just yesterday while experimenting with InSim buttons to try and draw road signs.Take a speed limit sign for example (Europe style): the sign is circular, with a white background, a red border, and black text stating the speed limit. We should be able to draw such a sign using 3 IS_BTN packets. LFS even supports the characters we want to use for that: ● for the background, ○ for the border, and digits for the text (for better control over border thickness, and due to general quality of large text rendering, I ended up using ● for the border as well, resizing the button appropriately). My understanding of InSim button z-order, through earlier testing, has been that buttons with a lower clickID are rendered first, and therefore buttons with a higher clickID appear on top. This is generally true... but not always!
Trying to render my speed limit sign, the text is nowhere to be seen, but if I add more text so it spills out of the sign, I can see it being rendered behind the sign, despite having a higher clickID (in the above example, the text reads "505050"). It would appear that characters from different code pages do not follow the clickID z-order, which becomes a headache when dealing with buttons. (for the record, in the above example, the border button has ID 0, the background button has ID 1, and the text button has ID 2)
Even better, this also applies to characters in a single button: in the following example, I created 2 buttons, same position, same size, with texts "^0●a" and "^7b", and here's what the result looks like:
We only have 2 buttons here, but the "b" character appears both in front and behind characters from the other button, simply because they're from different code pages!
It would be nice to get more info about the rendering logic, or whether this can be fixed for consistency, as it unfortunately makes it impossible to draw those signs, or any other kind of button combination that would rely on characters from different code pages (in this example, ● is converted to a Japanese code page character as [94, 74, 129, 156]).