[SOLVED] Japanise Character Fonts

ArchUser01Ger · 2026-07-01 10:30:42

Hello,

I have trouble with the display of Japanese characters. I do have fonts for them, but my system seems to prefer some other language for displaying these characters (I don't know which language, it is not simplified Chinese). Some websites display characters as Japanese but some display them differently. I tried following the steps on the arch wiki site Localization/Japanese and edited my /etc/locale.gen as described. I also changed the font fallback order on about:config for firefox to have Japanese at top. Does someone have an idea what else I can do, to ensure that han characters are displayed in their Japanese form? I uses hyprland by the way, if this is relevant.

Thank you very much!

Last edited by ArchUser01Ger (2026-07-02 18:00:07)

Nikolai5 · 2026-07-01 16:41:20

Can you confirm what you actually want to achieve?

Locales and fonts you see when browsing Japanese websites or when Japanese text is used somewhere are different things.
Locales control system language and regional formatting (for example: UI language, date formats, number formatting like 10,000.00 vs 10.000,00, sorting rules, etc.). This is what you would change if you wanted your desktop environment and system messages to be in Japanese.

If you just want to be able to use and read Japanese, you primarily just need the font packages installed that can display those characters and then its a case of whether the applications you use like browsers are picking those up correctly.
What font packages do you have, what issues exactly are you getting?

「これは日本語ですか？」Do you see the hiragana and kanji correctly?

Last edited by Nikolai5 (2026-07-01 16:42:21)

ArchUser01Ger · 2026-07-01 17:07:38

Hi, thanks for your answer, I am sorry if I have not been clear.

I do have Japanese Fonts and I can read what you wrote just fine. But if I type for example 平 on this website, it is displayed to me like 異体字 form you can see here: http://blog.livedoor.jp/atori_kotoba/ar … 33766.html. This is also what I see when I type 平 in my console (I use Alacritty). My goal would be to archive, that my system displays characters like this consistently in its Japanese form, be it on websites or on applications I use. Is there any way to archive this? (If I use Youtube or Wikipedia 平 looks right for me, so I must have the right font for it. But on some websites like for example this forum the character displays differently for me) .

EDIT: After investigating a bit further, I am pretty sure that the unicode poits are displayed in their Korean forms as standard for me. I have no idea why.

Last edited by ArchUser01Ger (2026-07-01 17:53:30)

seth · 2026-07-01 18:03:47

平 is 5e73
異 is 7570
体 is 4f53
字 is 5b57

And I assume you see them all as different glyphs so they're basically *displayed* correctly?

if I type for example 平 on this website

Assuming this is an input related problem, what https://wiki.archlinux.org/title/Input_method do you use and how is it configured?

Nikolai5 · 2026-07-01 18:36:14

ArchUser01Ger wrote:

Hi, thanks for your answer, I am sorry if I have not been clear.
EDIT: After investigating a bit further, I am pretty sure that the unicode poits are displayed in their Korean forms as standard for me. I have no idea why.

Yes, I've found actually its the same for me after comparing the character you reference to jisho.org

I am currently trying to adjust the fontconfig configuration files to pick up "Noto Sans CJK JP" instead. I'll let you know if I have any success with getting that to display 平 normally.

fc-match -s :lang=ja | head

I assume that returns a KR font as the first option for you?

seth · 2026-07-01 18:50:14

@Nikolai5 is this a recent regression introduced by /usr/share/fontconfig/conf.default/48-guessfamily.conf ?

Nikolai5 · 2026-07-01 19:05:15

I'm not sure, looking at that file, I don't see it as an issue, its quite simple/limited in what its doing.

It seems like some fall-back shenanigans beyond my knowledge, I've been playing around with a config file and with this:

 <match target="pattern">
  <test compare="contains" name="lang" qual="any">
   <string>ja</string>
  </test>
  <edit binding="strong" mode="prepend" name="family">
   <string>Noto Sans CJK JP</string>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>

I was able to get the output:

-> fc-match -s :lang=ja | head
NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular"

But it didn't actually "correct" the font within kwrite, or Firefox. I suspect if the language isn't being passed through by the application it is falling back to Korean due to some internal font ordering.
For example if I go to jisho.org and look at that character, it displays correctly on the page, but the tab title is different (Korean style). Likely because the web page was set up with specific web font rules in CSS, etc, but Firefox application itself has not picked that up from my system.

This is a can of worms of an issue I didn't even previously notice, any further developments or I learn anything else I'll let you guys know.

seth · 2026-07-01 19:07:39

I don't see it as an issue, its quite simple/limited in what its doing.

https://bbs.archlinux.org/viewtopic.php?id=313799 - there're several threads, it mostly botches resolution of generic families but the entire resolution stack changes.
Hence the primary question whether this is a regression.

ArchUser01Ger · 2026-07-01 19:15:30

seth wrote:

平 is 5e73
異 is 7570
体 is 4f53
字 is 5b57
And I assume you see them all as different glyphs so they're basically *displayed* correctly?
if I type for example 平 on this website
Assuming this is an input related problem, what https://wiki.archlinux.org/title/Input_method do you use and how is it configured?

If it helps: the glyph 平 is 5e73 looks for me like + U+E0101 or + U+E0103 on this site: https://www.chise.org/est/view/character/%E5%B9%B3 . I want it to look like + U+E0100 or + U+E0102 (I can't see a difference there). I don't think it is an input related issue, my input method is setup according to the wiki and works fine on most Japanese websites.

Thanks for all the effort by the way!

seth · 2026-07-01 20:30:04

link is 403 - this character??
All U+E010x are non-printable codepoints, it might help to link some screenshots, but have you tested Nokolai5's fontconfiglet?

ArchUser01Ger · 2026-07-01 21:16:48

Does this link work? https://imgur.com/a/z9d4GOC . The very first 平 in the word 平氏 on the top of the screenshot is displayed correctly (there where normaly the adressbar would be). All the other 平 that follow in the site itself are a (probably?) Korean version. My Output for:
fc-match -s :lang=ja | head
is:
NotoSans-Regular.ttf: "Noto Sans" "Regular"
NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular"
FreeSans.otf: "FreeSans" "Regular"
FreeSansBold.otf: "FreeSans" "Bold"
CaskaydiaCoveNerdFont-Regular.ttf: "CaskaydiaCove Nerd Font" "Regular"
ProggyCleanCENerdFont-Regular.ttf: "ProggyClean CE Nerd Font" "Regular"
ProggyCleanNerdFont-Regular.ttf: "ProggyClean Nerd Font" "Regular"
Font Awesome 7 Brands-Regular-400.otf: "Font Awesome 7 Brands" "Regular"
Font Awesome 7 Free-Regular-400.otf: "Font Awesome 7 Free" "Regular"
FreeMono.otf: "FreeMono" "Regular"

I am honestly not sure which config file I need to change to try Nokolai5's config, but I will try it out as soon as I find it.

seth · 2026-07-02 05:48:54

Ah, the diagonal bars point the wrong direction
Looks ok here, but I only installed 3 CJK fonts individually (which are sizable enough )
There's also https://archlinux.org/packages/?sort=&q … source-han (could be an issue w/ NotoSansCJK-Regular.ttc specifically?)

fc-match -s sans:charset=5e73                    
NotoSansJP-VariableFont_wght.ttf: "Noto Sans JP" "Regular"
NotoSansSC-VariableFont_wght.ttf: "Noto Sans SC" "Regular"
NotoSansTC-VariableFont_wght.ttf: "Noto Sans TC" "Regular"
SourceSansPro-Regular.otf: "Source Sans Pro" "Regular"
DejaVuSans.ttf: "DejaVu Sans" "Book"
DejaVuSans-Bold.ttf: "DejaVu Sans" "Bold"
DejaVuSans-Oblique.ttf: "DejaVu Sans" "Oblique"
DejaVuSans-BoldOblique.ttf: "DejaVu Sans" "Bold Oblique"
…

https://wiki.archlinux.org/title/Font_c … figuration
You can drop in a config file into eg. ~/.config/fontconfig/conf.d/99-biginjapan.conf but I suggest to try to remove /usr/share/fontconfig/conf.default/48-guessfamily.conf first (or to downgrade fontconfig to 2:2.17.1-1)

ArchUser01Ger · 2026-07-02 17:49:59

Thanks, I think installing adobe-source-han-sans-jp-fonts fixed it for me. fc-match -s sans:charset=5e73 now gives

fc-match -s sans:charset=5e73
SourceHanSansJP-Regular.otf: "Source Han Sans JP" "Regular"
NotoSansCJK-Regular.ttc: "Noto Sans CJK KR" "Regular" 
NotoSerifCJK-Regular.ttc: "Noto Serif CJK JP" "Regular" 
D2CodingLigatureNerdFont-Regular.ttf: "D2CodingLigature Nerd Font" "Regular" 
M+1CodeNerdFont-Regular.ttf: "M+1Code Nerd Font" "Regular" 
NotoSans-Regular.ttf: "Noto Sans" "Regular" 
FreeSans.otf: "FreeSans" "Regular" 
NotoSansBengali-Regular.ttf: "Noto Sans Bengali" "Regular" 
NotoSansAdlamUnjoined-Regular.ttf: "Noto Sans Adlam Unjoined" "Regular" 
…

and everything displays right after reboot. I am still a bit wondering, where this came from, I think until around a month ago the Characters where displayed right. But yeah, now it works, Thanks!

seth · 2026-07-02 18:31:58

I think until around a month ago the Characters where displayed right.

seth bets your right arm and wrote:

I suggest to try to remove /usr/share/fontconfig/conf.default/48-guessfamily.conf first (or to downgrade fontconfig to 2:2.17.1-1)

Beemo · Yesterday 08:43:10

Just ran into this issue as well. The cause of this issue is Unicode Han unification. When there is no hint (e.g. HTML language tag) for what the language is, the system has to guess / pick one based on some arbitrary order.
There are some suggestions on how to fix it*, but I haven't tried them: https://bugs.kde.org/show_bug.cgi?id=465384

p.s. well you can't really fix it, you can set a preference but it could always be wrong. E.g. prefer JP but someone sends you CN text.

EDIT:
Oh wow the Han unification situation is such a mess. In Noto Fonts there are JP (ja), KR (ko), SC (zh-cn), TC (zh-tw), HK (zh-hk). (And there are also zh-sg zh-mo in fontconfig.)
The solution in the link above doesn't work (at least now). There is also this online for older versions: https://www.zhihu.com/en/answer/104906870
Currently every distro has their own fix:
https://sources.debian.org/src/fonts-no … o-cjk.conf
https://src.fedoraproject.org/rpms/goog … fonts.conf

Last edited by Beemo (Yesterday 18:48:04)

Beemo · Yesterday 19:28:43

Ok the fix is 2-fold:
1. Different CJK variants can be used to render each other, which results in incorrect font even if the language tag is present (e.g. GitHub, Firefox): Apply the Fedora config, which strips other langs from the font save for itself. This is pretty safe IMO.
2. When no lang info is present, you can specify a preference / ordering: https://github.com/lch/fontconfig/blob/ … refer.conf
This is kinda not safe, as now "Noto Sans CJK SC" is preferred even for EN characters:

❯ fc-match sans:charset=007E
NotoSansCJK-Regular.ttc: "Noto Sans CJK SC" "Regular"

You can fix it by adding regular Noto Fonts at the front:

		<prefer>
			<family>Noto Sans</family>
			<family>Noto Sans CJK SC</family>
		</prefer>

Still kinda dodgy as you are now always preferring Noto Fonts...

Last edited by Beemo (Yesterday 19:29:23)

seth · Yesterday 20:01:38

Because the OP suggested this might be a regression and despite that pot. just being due to changes in the installed fonts: did you try to remove /usr/share/fontconfig/conf.default/48-guessfamily.conf ?

Beemo · Yesterday 22:16:53

@seth

$ fc-match sans:charset=76f4
NotoSansCJK-Regular.ttc: "Noto Sans CJK KR" "Regular"

$ sudo rm /etc/fonts/conf.d/48-guessfamily.conf
$ fc-cache -f

$ fc-match sans:charset=76f4
NotoSansCJK-Regular.ttc: "Noto Sans CJK KR" "Regular"

And yes I think installing fonts changes it, in the Live OS:

# pacman -S fontconfig

# fc-match sans:charset=76f4
AdwaitaSans-Regular.ttf: "Adwaita Sans" "Regular'

Which might be what people want on a GNOME desktop instead of Noto Fonts.

EDIT: nope even GNOME OS currently use DejaVu fonts as default.
Arch noto-fonts package sets Noto fonts as preferred so that's why the change: https://gitlab.archlinux.org/archlinux/ … type=heads

Last edited by Beemo (Yesterday 23:32:14)

Beemo · Today 02:15:36

Found the reason: https://gitlab.freedesktop.org/fontconf … 8b8750193c
This commit added Noto Fonts CJK KR as the preferred font.
If you have noto-fonts-cjk installed, before the commit JP comes first simply because it's the first font face in the file. After the commit, KR is preferred because of the config.

Arch Linux

#1 2026-07-01 10:30:42

[SOLVED] Japanise Character Fonts

#2 2026-07-01 16:41:20

Re: [SOLVED] Japanise Character Fonts

#3 2026-07-01 17:07:38

Re: [SOLVED] Japanise Character Fonts

#4 2026-07-01 18:03:47

Re: [SOLVED] Japanise Character Fonts

#5 2026-07-01 18:36:14

Re: [SOLVED] Japanise Character Fonts

#6 2026-07-01 18:50:14

Re: [SOLVED] Japanise Character Fonts

#7 2026-07-01 19:05:15

Re: [SOLVED] Japanise Character Fonts

#8 2026-07-01 19:07:39

Re: [SOLVED] Japanise Character Fonts

#9 2026-07-01 19:15:30

Re: [SOLVED] Japanise Character Fonts

#10 2026-07-01 20:30:04

Re: [SOLVED] Japanise Character Fonts

#11 2026-07-01 21:16:48

Re: [SOLVED] Japanise Character Fonts

#12 2026-07-02 05:48:54

Re: [SOLVED] Japanise Character Fonts

#13 2026-07-02 17:49:59

Re: [SOLVED] Japanise Character Fonts

#14 2026-07-02 18:31:58

Re: [SOLVED] Japanise Character Fonts

#15 Yesterday 08:43:10

Re: [SOLVED] Japanise Character Fonts

#16 Yesterday 19:28:43

Re: [SOLVED] Japanise Character Fonts

#17 Yesterday 20:01:38

Re: [SOLVED] Japanise Character Fonts

#18 Yesterday 22:16:53

Re: [SOLVED] Japanise Character Fonts

#19 Today 02:15:36

Re: [SOLVED] Japanise Character Fonts

Board footer