Closed fhfuih closed 1 year ago
My real problem is: kitty is using a Trad.Chinese (Hong Kong) glyph variant of the Simp.Chinese font variant of the system font. I think LANG should be the cause.
LANG does nto control font fallback. That is done my CoreText. You can use --debug-font-fallback to see which font is used for a given symbol. And you can override it with symbol_map in kitty.conf.
Not directly, but to some extent I think it is, I will explain it below. @kovidgoyal I understand you have spent many times explaining this, but please read the detailed explanation below of my experiment:
When I open a kitty --debug-font-fallback
from within a kitty term, the sub-kitty can pick up the LANG=zh_CN.UTF-8
env. (I will not post the kitty debug log here. But LANG is correctly set) Also, the parent-kitty says
U+9aa8 bold Face(family=PingFang SC, full_name=PingFang SC Semibold, postscript_name=PingFangSC-Semibold, path=/System/Library/Fonts/PingFang.ttc, units_per_em=1000, ascent=27.6, descent=8.8, leading=0.0, point_sz=0.0, scaled_point_sz=26.0, underline_position=-3.9 underline_thickness=2.1)
OK So the SC (Simplified Chinese) font variant is chosen. In return, the character glyphs are in Simp.Chinese variants:
But back in the parent-kitty term, directly opened from app dock, has LANG=zh_HK.UTF-8
. In return, the character glyphs are in Traditional Chinese (Hong Kong) variants:
This documentation from Noto Sans CJK a.k.a. Source Han Sans demonstrates the difference between CJK regional difference:
I don't how to --debug-font-fallback
the parent-most kitty process that's directly spawned from the app dock (and I would like to help investigate if you tell me how!). So there can be two possible causes
Recall that my localization settings are
Primary Languages:
Simplified Chinese
Traditional Chinese (Hong Kong)
English (US)
English
Region:
Hong Kong
1 maybe the parent kitty failed to set LANG=zh_CN.UTF-8
even if I write env LANG=zh_CN.UTF-8
in kitty.conf. Then kitty tells the system to look for a font fallback for zh_HK
instead (The parent kitty sees LANG=zh_HK.UTF-8
)! Then it uses PingFang HK
instead of PingFang SC
in this process.
2 Most modern CJK UI fonts (including PingFang) also include all regions' glyph variants inside a specific font variant. So inside PingFangSC, there exists HK,TW,JP,KR variants. These glyph variants are normally not enabled unless the current text is tagged as in those languages. Specifically in PingFing, seems they put non-default regional glyph (i.e. HK, TW, JP, KR. Default is SC in PingFangSC font variant) variants in custom cvxx
features, and the feature lookup table enable one, if only necessary, according to language tag & script tag. Perhaps the parent kitty uses PingFang SC
successfully. But the env LANG=zh_HK.UTF-8
triggers the HK glyph variant of the SC font variant.
I'm a newbie to anything behind OpenType, so that's the most I know. In either case, I think it may work to somehow make sure the parent-kitty pick up LANG
env according to kitty.conf
. (And not picking up LANG should be a kitty bug, not a feature request. Because the kitty doc explicitly invites us to specify LANG in kitty.conf
if intended)
For the second case, another solution may be to allow us to configure font script_tag or language_tag, in addition to feature_tag. This is a feature request though, and is rather ad-hoc. Since another CJK font (e.g. Noto Sans CJK) may implement the regional glyph mechanism in another manner with another feature name, setting feature_tag may be cumbersome. (And I tried setting PingFangSC's feature_tag -cv08 -cv09
in kitty.conf
with no luck...) As long as the script_tag or language_tag are correctly set, the font should give us the expected glyph.
Except that in terminals there is no language tagging. Fallback symbols are not queried by language, only by unicode code point. IIRC kitty uses CTFontCreateForString, see core_text.m for details. It could well be that CoreText itself reads the LANG variable for this, though I doubt it.
And env has no effect on the environment for kitty itself, since kitty has to start before it can read kitty.conf. It matters only to the environment of child processes.
On macOS if LANG is not set when kitty starts, kitty will query Cocoa to determine the lang, see the function coca_get_lang() which works by querying NSLocale for lang code and countrycode. If that's not returning the right value on your system, there's not much kitty can do about it. You can debug the env vars kitty sees here: https://sw.kovidgoyal.net/kitty/faq/#things-behave-differently-when-running-kitty-from-system-launcher-vs-from-another-terminal
Thanks for the info. Could you teach me how to see font fallback of the kitty instance directly opened from app dock just like --debug-font-fallback
? I am not familiar with mac programming; maybe I can check the font fallback first before continue investigating. Thanks
See the kitty FAQ it tells you how to specify command line options for macOS dock launches. IIRC the stderr of such processes is available via Console.app though I am not sure about that.
That's strange. I self-compiled a kitty (at tag v0.26.5, the latest release, the version I'm using now) only with a few additional lines to os_log
the font fallback lines. (originally printf
ed, which is not accessible on macOS).
Now the self-compiled kitty.app
works fine even if it sees env=zh_HK.UTF.8
. The PingFang SC
font is chosen, and the default SC glyph variants are displayed.
Can it be the build toolchain or build environment? I doubt but is there any other possible explanation for that?
On Sun, Jan 15, 2023 at 10:24:29AM -0800, Zeyu Huang wrote:
That's strange. I self-compiled a kitty (at tag v0.26.5, the latest release, the version I'm using now) only with a few additional lines to
os_log
the font fallback lines. (originallyprintf
ed, which is not accessible on macOS). Now the self-compiledkitty.app
works fine even if it seesenv=zh_HK.UTF.8
. ThePingFang SC
font is chosen, and the default SC glyph variants are displayed.Can it be the build toolchain or build environment? I doubt but cannot come up with another conclusion
I dont see how.
Describe the bug
I am a macOS user with localizations settings as:
locale
give meBut kitty debug info gives me
Note in the debug output that: I have set
env LANG=zh_CN.UTF-8
, but kitty stills seezh_HK.UTF-8
To Reproduce
Steps to reproduce the behavior:
Screenshots
NA
Environment details
Attached above
Additional context
NA