|
Bugzilla – Full Text Bug Listing |
| Summary: | locale language environment, fonts fallback doesn't work. | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Chanryul Yoon <razorbacky> |
| Component: | Other | Assignee: | Forgotten User DV81ZEWZkN <forgotten_DV81ZEWZkN> |
| Status: | NEW --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | matz, qzhao, razorbacky |
| Version: | Current | Flags: | chcao:
needinfo?
(razorbacky) |
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE Tumbleweed | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
en_US.UTF-8
ko_KR.UTF-8 |
||
Created attachment 870611 [details]
ko_KR.UTF-8
Hi Andreas, would you please help to take a look at this issue? I'm not sure whether it is correct to assign it to you, please feel free to reassign whenever necessary, thanks. (Andreas is on vacation, so I'm answering). No, this doesn't have to do with glibc Chenzi. If anything is broken (I can't say, it might also be a mis-configuration of the themes, or in oh-my-zsh, or whatever the user is using to produce this output) then it's somewhere in the GUI components, particularly the terminal emulator that's used. If I take a guess, then the shown terminal output is from the 'powerlevel10k' theme configurator of zsh, at https://github.com/romkatv/powerlevel10k/blob/master/internal/wizard.zsh If my guess is correct then the character shown below the 'is this a lock?' question is either Unicode code-point \uF023 or \ue138. You can check if any of the glibc routines have any effect by doing this: % echo $'\uf023\ue138' | hexdump -C 00000000 ef 80 a3 ee 84 b8 0a |.......| 00000007 in both locales. There should be no difference. Both codepoints are in the private-use area of Unicode, and seemingly the used terminal emulator somehow renders them differently depending on the chosen locale. That might or might not be depending on which other fonts are configured for the terminal emulation. It's quite possible that, when using a korean locale, that an additional fall-back font sits in the layer of fonts that prevents it from seeing the 'lock' graphem. Either way, that all has to do with the terminal emulator and the widget toolkit it is using, nothing to do with glibc. So, back to screening. (I'd guess the next best assignee is either KDE or GNOME, whatever desktop env is used by the reporter). Big thanks to Michael for taking look at this issue! @Chanryul, what desktop you are using please? (In reply to Chenzi Cao from comment #4) > Big thanks to Michael for taking look at this issue! > > @Chanryul, what desktop you are using please? OH!, I've been waiting for a really long time. i using openSUE Tumbleweed, but, it is not different. because, this Symptom is same on openSUSE leap. From the bug report, at least font fall-back is font-config's duty, there's no relationship to GNOME. |
Created attachment 870610 [details] en_US.UTF-8 # reference what is this component. I reproduced the phenomenon in a virtual machine to maintain my normal environment. Font fallback does not work in two identical environments with different language locales. one, LANG=en_US.UTF-8 the other one, LANG=ko_KR.UTF-8 (please attached images) fallback to awesome fonts. LANG=en_US.UTF-8 environment font fallback is work. but, LANG=ko_KR.UTF-8 environment font fallback doeson't work.