- From: 木田泰夫 <kida@mac.com>
- Date: Wed, 10 Mar 2021 14:37:40 +0900
- To: Koji Ishii <kojii@chromium.org>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-Id: <28F51B8A-94D9-4EAE-A858-0BBFB82995D4@mac.com>
石井さん、 Meeting notes draft にも書きましたがまさにこの議論がありました。現在 CID フォントの多くは比較的(ヒラギノでちょっと乱しましたが ;)仕様が統一していますが、TrueType はバラバラ。これは別に開発者が意図的にそうしたかったわけではないと思うんですよ。単に基準がなかった。 そういう意味で Adobe-Japan1 が CID フォントに果たしてきたようなガイドラインや定義があると良いと思います。これもやってゆきましょう。 木田 > 2021/03/09 18:08、Koji Ishii <kojii@chromium.org>のメール: > > 小出しですみません、もう一つ。JLTF reference実装のペア定義とかがあると、フォント製作者には助かるかもしれないですね。軽くテストしたところでは、縦書きのクオート類 <https://twitter.com/works014/status/1359353303151169537>や下付きのクオート <https://twitter.com/works014/status/1359836250887254016>とか、JISにない全角括弧類とかは、フォント間の互換性が低くて、とりあえず "if font is Meiryo <https://github.com/kojiishi/contextual-spacing/blob/master/EastAsianSpacing.py#L89>" みたいな処理を入れています。この辺が、村上さんがおっしゃられていた「フォントがやるべき」という話になるんだと思いますが、フォント製作者も投げられても戸惑う場面があるかと思うので、指針があるといいのかなと思っています。 > > On Tue, Mar 9, 2021 at 5:42 PM Koji Ishii <kojii@chromium.org <mailto:kojii@chromium.org>> wrote: > 木田さん、お返事ありがとうございます。ご質問のお返事をインラインで。 > > On Tue, Mar 9, 2021 at 9:12 AM 木田泰夫 <kida@mac.com <mailto:kida@mac.com>> wrote: > 石井さん、ありがとうございます。入りましたか。 > > これはフォントに chws テーブルがないと動かないのですよね? > > はい。 > > いくつか質問が: > ・chws をきちんと読めと言われそうですが、カバーされない場合など、我々が注意すべき点はありますか? > > 現時点、JLREQのすべてのケースはカバーできていません。いろいろな考えがあると思いますが、私がこれをデザインした時点での第一のモチベーションは、まずは実装をなるべく広げることであり、約物が連続するなど「まばら度合い」がより目立つ部分があらゆるアプリケーションで処理できることを優先しています。カバーするケースを増やすことは徐々にやっていければ、と思っています。 > > JLTFでもご検討いただけるのであれば、2つの側面があるかと思います。一つは、実装を広めるにはどうすればいいか。もう一つは、現在カバーできていないケースをどうやって広い実装に導いていくか。 > > 処理するペアがフォント側に記載されるので、フォント固有の挙動を入れられる、例外的なフォントをアプリで処理する必要がない、などのメリットがある反面、フォントデザイナーが決めなければいけない、というのはデメリットにもなりうるとも思っています。日本語では、フォントデザインと組版技術が割と離れているので、どうやって広めていくか、とか。また、CSSとの関連などもどこかで整理する必要があるかもしれません。こういったところの課題出しも大きくプラスになるかと思います。 > > ・これが入っているフォントとそうでないフォントとを、レイアウトを行う側で見分けて動作を変える必要がありますね? > > これは、必要ないようにデザインされています。機能はデフォルトオフなので、WordやInDesignなどエンジン側で処理するアプリは、今まで通りで、変更の必要がありません。これらのアプリがフォントごとに詰め処理をチューニグしたい場合には、halt <https://docs.microsoft.com/en-us/typography/opentype/spec/features_fj#tag-halt> を使います。 > > レイアウトエンジン側で詰め処理を持たないアプリの場合には、chwsをオンにすることで、chwsに対応したフォントであれば、連続役物が正しく処理されます。ChormiumはM90からデフォルトオンですが、このページ <https://kojiishi.github.io/chws/test.html> のように font-feature-settings <https://developer.mozilla.org/ja/docs/Web/CSS/font-feature-settings> でページ作者がオンにすることもできます。 > > ・今後は全てのフォントがこのテーブルを備えるべき、という方向にすべきですか? > > 私はそう思っています。そういう活動をしていくつもりでもあります。Wordに実装した1993年頃、フォントでやるべきじゃないかという意見がありましたが、その方法だと全部のフォントに入るのに10年かかるよ、と思ったのを覚えています。それから28年経って、未だにWordやInDesignなど、ごく一部のアプリでしか実装できていません。次の10年後には、間延びした連続役物を撲滅できているといいなと思っています。 > > JLTFでもご賛同いただけるなら、非常に心強いです。 >
Received on Wednesday, 10 March 2021 05:38:04 UTC