W3C

– DRAFT –
(MEETING TITLE)

18 May 2021

Attendees

Present
Atsushi, Kida, Koji, Kyo, Miyata, miz, Murata, Nat, shinyu, Tahara, Tajima, tatsuo, Toshi, 中内
Regrets
-
Chair
-
Scribe
atsushi

Meeting minutes

recap

Kida: 前回は縦書き横書きの字形の話をした
… ややこしげな例の資料を出していただけるというのは次回に回す
… Ishiiさんに半角詰め(chws)についての説明をいただいて議論をした
… フォントの方々から、フォント自体のアップデートをどうやってやるかという話をご紹介いただいた
… 半角詰めについて、chwsではダメな事例があるという指摘をいただいた。行頭・行末、複数フォントの混在、より細かい調整をしたいとき。hlbテーブルで大丈夫なのか?十分という結論になったか?

該当のgithub issue

Nat: CGのミーティングで説明した
… chwsと詰め・空きの問題について議論はした
… issueとは話がずれた議論になってしまっていた

kida: chwsが必要な理由について、パフォーマンス問題について石井さんから指摘をいただいた

今回の議題

kida: 行頭・行末、マルチフォントについて、石井さんの考えを伺い、議論したい
… chwsを加えることについて、また、フォントをアップデートをすることについての大ごとさを前回離開したつもりである
… という中で、縦横問題も全部解決した仕様を提示するというのがよいのかな、という印象がある
… その全体的な解決策の仕様を作るためにどういうことが必要なのか

ishii: まず、バージョン、ひとまとまり、という話について、個人的にはレベルがあるのかなという感じを受けている。ウェブフォントのベンダーはだいぶ違う可能性。

ishii: 印刷事故に直結するベンダーと、そうでないベンダー。エンタープライズ方面と似たような議論で。
… 最終的に揃うというのは重要なんだとは思うが、枯れた技術しか入れないところもあるだろうし、すぐに更新するところもあるだろう。
… そのなかで、長い目でどこに向かおうかを考えつつ、実装をひとつづつやっていければいいなと

ishii: 行頭行末、個人的にはhaltを適用する、shaping engineにレベルがある。OSSのhalfbuzz、Android Chrome, Firefox, Linuxなど、一つのフォントをすべて一括してshapingする、フォントとフォントの間は上のレイヤーでやってもらうというもの
… 残り2つ、core textとdirect writingは、もう少しハイレベルで、行単位・段落単位の処理も可能になっている
… エンジンによって事情が違うのは、OFFの機能を使うと、エンジンでやるしかないのとコアでやってくれるものの違いが出てくる。
… という意味で、行頭行末をどこで処理するかというのはエンジンによって変わる
… halfbuzzでいうと、欧文で言うoptical bounces、行頭行末にO/Tなどが来た時に少しはみ出させる処理、というのはアプリでフィーチャーを有効にするなどの処理しないといけない
… 基本的にはそれと同じパターンといえる

kida: つまり、フォントという意味で言うと、haltがあると十分といえる。chwsがあるという理由はパフォーマンスというのは理解したが、同じようなものがあるか?

ishii: 全文字に掛ける必要があるchwsと違い、あまり出てこない行頭行末の再処理はそこまでパフォーマンスには影響しない

nat: chwsとhaltは処理が違うし、機能としても違う
… haltは半角にできるものはすべて半角、chwsは半角にしたいものについてのみ半角にするという機能
… chwsの方が適用されるべきターゲットは少ない範囲、連続した約物を半角にさせるなどのところの対処向け
… より高度な文字組としてはもっと複雑なことをやらないといけないが、この2つでできるのは一番基本的なところ

kida: これまでの理解として、OSレベルで可能な限りの処理ができるようになってほしい、またそれに加えてパフォーマンスも落ちない程度で何かやれる方策が欲しい、というところ
… もっと精緻なレイアウトが必要な場合はより高度なことを後で書ける

ishii: マルチフォントはもっと厄介である
… いにしえのwordみたいな決め打ちだったら楽だけど、多様なバリエーションがある現在、フォントによって半角・全角などの構造が違う。ということで、それぞれのフォントに情報を持たせることが必要となる。
… サイズが違うという話だけであればルールに従ってやればいいが、両側で削れる割合が違った場合どうするかなどの処理が難しい
… haltだと全部削った後に2分のスペースを入れるという処理になる
… chwsではフォントにやらせるので、フォントデザイナの指定での処理ができるようになる

kida: その部分がchwsで有利な処理である
… マルチフォント・割合が違う場合にどうすべきかというのをjlreq的に何か提示すべきか?

ishii: 技術論から離れて、フォントサイズが違う場合どうするかというのは決めやすい
… フォントサイズが違って、かつ、詰められる割合が違う場合にどういうような処理を行う必要があるか、というのは日本語組版として提示すべきでは

nat: 両側のそれぞれで削る量から平均を取るなどとか?

kida: どういうような組版になるべきか、どれくらいの間があるべきか、ということを議論して文書化しないといけない

toshi: JIS X 4051の規定は参考にならない
… そのケースについては書いてあるが、その当時に多くあった令を前提に書いてある。なので、大きい括弧が入るような事例は考えてなかった。小さいのが混じるときとかだけがある。
… ishiiさんの話の通り、一つは平均をとるという方法、もしくはわたしは大きい方が勝つという処理がいいと思う。
… どちらがいいかというのはどっちでもいいのではないか。大きい方が勝つというのが論理的にはあってるとは思うが。

kida: jlreq github issueとして建てよう

ishii: 筆文字で半角にできない、70%にはできるというのが出たときにどうするか?

toshi: 考え方として、全部詰めてから空きを入れる?70%まで詰めてから2分を入れるというのは?
… もしくは最終的に全部の幅で2分の空きを持ったような出力になるがいい?

kida: 処理を考えずにどういう表現が欲しいかという点では?

toshi: そこをどうするかについて意見の一致はないのではないか?

toshi: 詰めた後で空きが2分になればいい、というような考えではどうか?
… 意見をまとめてメールで流す

nat: 行書、プロポーショナル、で組むものについて、空きが2分、全角・半角などの考え方からは離れていて、別な考え方が必要なのではないかという気はする
… 全角に戻してからスペーシングをいじるなどというのはちょっと違うのではないか

kida: 全角信仰というものに合わない、活字になかった新しいプロポーショナルという現象にぶち当たっているのかな?

toshi: 余談だが、昔からプロポーショナル問題はある。活字時代に鍵括弧やパーレン、字形が2分、空きが2分、だったが、2分は開きすぎだという議論は昔からあった。
… もしくは鍵括弧を全部四部とか。活字では難しかったからやっていなかった。
… パーレンについては、欧文が1/3だった。というのを2分の活字に入れ込んで組んだというような事例はあった。
… なにの2分にするのがいいかを調整したいなという話を思っている人はいるのではないか

ishii: 詰め組みと指定して戻ってきたものをなおさないといけない場合がある。全文にその指定をし直すというのは無理なので全角進行でやっていた。
… が、処理ができるようになって詰組みで
… 組んでみるということをやっている

toshi: 見出しと本文で別な組処理を行うというのはやっている
… 行頭行末をそろえてしまった時点で、約物を詰めるか、調整を避けるのを優先するか、という話が出てくる

kida: 前からゆっている、日本語もラグでいいのではないか?というのに近づいている

toshi: 認めていいとは思うが、習慣の問題でもあるので、なじみが増えてこないと?
… 欧文はいまは圧倒的に不ぞろいになっている
… 日本語でもいずれなってくるのではないか?

グリフが全角かどうかを見分ける方法について

ishii: 結論から言うと難しい。MLへのメールを参照

AOB?

toshi: コーテーションマークについてメールを流した

kida: ishiiさんに見てもらういい話だとおもう

ishii: chws/halt出たらない機能があるかどうかについて、chromiumでは行けると思うが、もっとアドバンスドで足らない可能性はあるとはおもう
… OTFでテーブルの機能が重複する分には問題ないので不足なら足すという手もある

nat: chwsはいまの定義だと他の機能と併用できない?

ishii: 行頭をhaltでやるならchwsはそれには書けない
… 続く文字についてはコンテキストがあるので掛けるかけないの分ける処理は問題ない

文字情報技術促進協議会との関係

kida: 来ていただいている方に対して、JLTFはzoom以外でも議論しているが、on-goingな議論をどうするかという話をしたい
… JL-TF MLではフォントに限らない全般の話をしているので、フォント以外の話が邪魔になる?
… もしくは別なオプションとしてW3C github issueでやるという手もある
… か、協議会の方でのツールで行うという手もある
… どうしましょうか?
… 全体に参加されたいという方はいらっしゃいますか?

tahara: 全体に参加という希望者がいるかもしれないが、フォントの話をする際にバックグラウンドの分かりにくさというのがある気もする

kida: 全体に参加されたい場合はわたしまでご連絡を

次回

kida: 議論項目としては、縦横問題に戻る
… フォントは何をすべきか、フォントの上のレイヤーは何をすべきかという議論。そして現状認識。Natさんのデータをもとに。

kida: 6/15 10am JSTにする

JL-TF フォントミーティング

Minutes manually created (not a transcript), formatted by scribe.perl version 131 (Sat Apr 24 15:23:43 2021 UTC).

Diagnostics

No scribenick or scribe found. Guessed: atsushi

Maybe present: ishii