Created attachment 66116 [details] screenshot Start a terminal in wide CJK mode (ie "VTE_CJK_WIDTH=wide LANG=zh_CN.UTF-8 vte2_90" or "VTE_CJK_WIDTH=wide LANG=zh_CN.UTF-8 gnome-terminal --disable-factory"), then run journalctl --setup-keys. The printed QR code is badly broken, because it's created using the block characters which get width 2, mixed with spaces that get width 1.
Hmm, I have now clue about the wide CJK mode. How can we change to the normal mode before printing the QR code?
So the problem is actually more complex than I first thought: * LANG=zh_CN.UTF-8 => works fine * LANG=zh_CN.UTF-8 VTE_CJK_WIDTH=wide => fails * LANG=zh_TW.BIG5 (or zh_CN.GBK, zh_CN.EUCCN etc) => fails dramatically For the problem in the 3rd case, you can use the ISO 2022 sequence ESC %G to switch to UTF-8 temporarily before starting the QR code, and then afterwards use ESC %@ to switch back. With that, the QR code shows up fine. This works in vte but not in urxvt, xterm or konsole (but doesn't make it any worse either). Now for the 2nd case, this doesn't work because of the way VTE_CJK_WIDTH=wide works; this may be a vte bug, not sure.
Hmm, so I now added code to systemd to skip the QR code entirely if nl_langinfo(CODESET) is not UTF-8. We probably should not attempt outputting UTF-8 if this is not enabled. I guess this "fixes" the 3rd case too, right? (Of course, it will make the QR code unavailable, but then again how would we even recognize BIG5 terminals that are also capable of UTF-8?) Leaves the 2nd case. If there's an escape sequnce to temporarily switch of the wide CJK stuff I'd be happy to merge that.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.