Open dertuxmalwieder opened 6 years ago
In earlier versions, this was resolved by running the program with a -u
to enable utf8 support.
In the current version, this won't work. The program will run, but will crash when a utf8 multi-byte glyph is rendered due to a known but untracked bug in the as/fonts
package.
Ultimately, there should be a way to render valid utf8 runes and revert to byte representation when an error replacement character is normally encountered. I haven't looked into that yet, but there would need to be an efficient way of doing that.
In the meantime, this is a good reminder for me to write up that fonts bug and fix it when time permits so that the -u
flag actually works.
Wouldn't it make more sense to have a
support UTF-8 by default?
Yes, eventually. The problem of utf8 not being idempotent prevented this from being the default before (invalid utf8 is converted one way into a replacement character which is unacceptable for binary files).
The flag -u
is off by default because it's not well tested yet, but it shouldn't crash when enabled anymore.
FYI, -u
is still not quite working.
New Windows 10 machine, fresh Go installation, typing "Zäune und Bäume" ("fences and trees", does not need to make sense, does it?) inside a -u
:
You might see the superfluous spaces.
I press "test äöüß".
a
gives me: