Bug 54062 - journalctl --setup-keys prints unreadable QR code in wide CJK mode
Summary: journalctl --setup-keys prints unreadable QR code in wide CJK mode
Status: NEW
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
Depends on:
Reported: 2012-08-25 20:05 UTC by Christian Persch (GNOME)
Modified: 2012-09-12 22:00 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

screenshot (61.84 KB, image/png)
2012-08-25 20:05 UTC, Christian Persch (GNOME)

Description Christian Persch (GNOME) 2012-08-25 20:05:06 UTC
Created attachment 66116 [details]

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.
Comment 1 Lennart Poettering 2012-09-12 07:11:57 UTC
Hmm, I have now clue about the wide CJK mode. How can we change to the normal mode before printing the QR code?
Comment 2 Christian Persch (GNOME) 2012-09-12 12:01:14 UTC
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.
Comment 3 Lennart Poettering 2012-09-12 22:00:05 UTC
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.