- From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
- Date: Mon, 19 Dec 2022 00:34:15 +0900
- To: Nat McCully <nmccully@adobe.com>
- Cc: Taro Yamamoto <tyamamot@adobe.com>, 敏 小林 <binn@k.email.ne.jp>, Koji Ishii <kojii@chromium.org>, 泰夫 木田 <kida@mac.com>, public-i18n-japanese <public-i18n-japanese@w3.org>
- Message-ID: <CALvn5ED7rsGHTGk5QKt=FR4OftOH4kWBRwGVDWsZqx30iG0ZHA@mail.gmail.com>
Nat, I am saying that OFF fails to clearly state conformance requirements. Meanwhile, you are talking about the background or rationales behind conformance requirements. Our concerns are orthogonal, as I see it. I personally do not care about the rationales behind conformance requirements. Your remarks are certainly useful and should probably be added as a note in OFF. Regards, Makoto 2022年12月18日(日) 23:55 Nat McCully <nmccully@adobe.com>: > Actually, the problem is that the spec and the kern featur originally only > considered Latin proportional typography. When Japanese fonts introduced a > design that was monospaced for part of its repertoire and proportional for > the other, there exists a conundrum. How to make kerning optional for only > part of the font and normal for the other part? That was how palt was > introduced and that is why it can be confusing until you think through the > technical limitations of the font format such as glyph number limitations > and kerning table limitations etc. > If the font is monospaced and you want to optionally kern it with a kern > feature, you need kerning pairs for all combinations of glyphs. No one does > this, so everyone thinks the kern feature if it exists is required. This is > true for Latin but not for Japanese fonts. Japanese fonts usually are > monospaced for the Japanese glyphs and proportional for the Latin, so the > kern feature is usually turned on only for the proportional glyphs and > requires the monospaced glyphs to be made proportional by palt before you > can apply kern to them. Most people do not understand this technical > detail. > > —Nat > > —Nat > ------------------------------ > *From:* MURATA Makoto <eb2m-mrt@asahi-net.or.jp> > *Sent:* Sunday, December 18, 2022 5:17:43 AM > *To:* Taro Yamamoto <tyamamot@adobe.com> > *Cc:* 敏 小林 <binn@k.email.ne.jp>; Koji Ishii <kojii@chromium.org>; 泰夫 木田 < > kida@mac.com>; public-i18n-japanese <public-i18n-japanese@w3.org> > *Subject:* Re: CJKフォントのpalt(詰め組)とkernの関係 > > > *EXTERNAL: Use caution when clicking on links or opening attachments.* > > > 山本さん、 > > 有難うございます。 > > 文面を読んでみて、山本さんの主張している内容は、こ > の規格には適合性要件として記述されていないと判断し > ます。以下、その理由を詳しく説明します。 > > まず、OFFは何を規定しているか?スコープを読むと、二 > つのことを規定しているようです。一つは、フォントを > 表すデータ形式です。もう一つは、font rendering and > text layout/shaping enginesの挙動です。 > > しかし、font rendering and text layout/shaping > enginesとは何かの定義はOFF規格書のどこにもありませ > ん。そして、enginesを主語としてshall, are required > to, shouldで始まる文も一つもありません。つまり、 > font rendering and text layout/shaping enginesの適 > 合性要件はOFFには規定されていないと私は判断します。 > > 次に以下の二つの文について論じます。 > > >If 'kern' is activated, 'palt' must also be > > activated if it exists. > > > うるさいことを言うと、ISO/IECでは適合性要件を書くた > めにmustは決して使ってはいけません(mustを使うと、 > 法律など規格でないものが定めた要件になります)。大 > 目に見ることにして、mustはshallのタイポだと思うこと > にします。 > > さてこの二つの文はフォントというデータの適合性要件 > を書いているのでしょうか?それとも、font rendering > and text layout/shaping enginesの適合性要件を書いて > いるのでしょうか?私にはどちらなのかよく分かりませ > ん。 > > kernをもつフォントは、paltが必須なのでしょうか?if > it existsという条件があるところを見ると、どうやらそ > うではなさそうです。kernを持つがpaltを持たないフォ > ントは許されているような気がします。 > > activateという語は、rendering and text > layout/shaping enginesの挙動を意味するので > しょうか?だとすると、これらの文はフォントの > 適合性要件をまったく規定していないことになります。 > > 以下の四つの文のどれが山本さんの意図と合っていますか? > > 1) kernを持つフォントは、paltは持たなければならない > > 2) kernを持つフォントは、paltを持ってもよいが、持た > なくてもよい。 > > 3) フォントのkernを考慮してglyphの位置決めを行う > engineは、paltも考慮しなければならない。 > > 4) フォントのkernを考慮してglyphの位置決めを行う > engineは、paltを考慮してもよいが、しなくてもよい。 > > 村田 真 > > 2022年12月18日(日) 7:03 Taro Yamamoto <tyamamot@adobe.com>: > > > > - 書かれているか具体的に教えていただけますか? > > > > p. 585 (‘kern’), p. 596 (‘vpal’), p. 624 (‘vkrn’, ‘vpal’)のFeature > interactionの項目に、’kern’と’palt’, ‘vkrn’と’vpal’との関係が書かれています。 > > > > 山本 > > > > > > > > > > -- > Regards, > Makoto > -- Regards, Makoto
Received on Sunday, 18 December 2022 15:35:05 UTC