Re: [csswg-drafts] [css-fonts-4] font-kerning:normal and CJK fonts with kerning pairs for fullwidth not well defined (#6723)

@kojiishi:
> With the current shaping engine APIs, it's not easy for browsers to apply features only if glyphs are fullwidth.

Does this mean that it is difficult to not apply 'kern' only if glyphs are fullwidth?

In @fantasai's [suggestion](https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1411487571), “2. kern non-CJK† only” does not require checking if glyphs are really fullwidth, because “† The appropriate division here is probably East Asian Wide vs others.”

This better default font-kerning behavior “kern non-CJK only” is already [implemented in Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1797431) (effective when `font-kerning: auto`. Their `font-kerning: normal` corresponds to `font-kerning: all` in the new proposal here).

I think this default “kern non-CJK only” is very nice for most CJK fonts. However, this may be not good for some not very common CJK fonts which have proportional CJK glyphs by default (not by 'palt') and have kerning feature. I am not aware of such Japanese fonts, but it would be possible. (MS PGothic and MS PMincho are well known examples of Japanese proportional fonts, but they have no kerning feature.)

On Korean font kerning, [Requirements for Hangul Text Layout and Typography - §2.4 Kerning for Hangul Fonts](https://www.w3.org/TR/klreq/#fonts-kerning) is very interesting.

[AG Ahnsangsoo 2012](https://fonts.adobe.com/fonts/ag-ahnsangsoo-2012) is a proportional Hangul font family with kerning feature.

Kerning should be enabled for CJK text by default for such fonts. So I think the normal font-kerning behavior should be corrected to: 

- If the font has palt/vpal feature, kern non-CJK only, otherwise kern everything.

Is this difficult to implement?


-- 
GitHub Notification of comment by MurakamiShinyu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6723#issuecomment-1454783131 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 4 March 2023 15:49:03 UTC