Re: JLreq TF フォント分科会は明後日 4/20 火曜日 10:00 (JST) から

 shimonoです

On 2021/04/18 20:13, MURATA Makoto wrote:
> FONT AND TEXT COMMUNITY GROUPはどうですか？
> 
> https://www.w3.org/groups/cg/font-text <https://www.w3.org/groups/cg/font-text>

 そこに"議論として"持ち込むのは一つの有効な手だとは思うんですが、、CGなんですよね、これ。
 どちらにしても、多分、有望エスカレーション先としてはCSS WGということになりそうな。。。


> 私はSC29にフォントがあるのがまったくおかしいと
> 思うので、あそこからフォントを取り上げたくて
> 仕方がない。

 セイジコワイ


> 
> 2021年4月18日(日) 19:50 Atsushi Shimono (W3C Team) <atsushi@w3.org <mailto:atsushi@w3.org>>:
> 
>      みなさま
> 
>      接続情報はこちらをご覧ください（いつもと同じです
>     https://www.w3.org/2021/04/jlreq-meeting-info.html <https://www.w3.org/2021/04/jlreq-meeting-info.html>
> 
> 
>     On 2021/04/18 11:46, 木田泰夫 wrote:
>      > JLreq TF の皆さま、
>      >
>      > フォント分科会が明後日 4/20 10:00 からです。
>      >
>      > 今回の議題は半角ツメの問題です。石井さん提案の OpenType テーブルを中心にした話題になるかと思います。まず石井さんに説明をしていただいて（*石井さん、お願いできますか？*）、いくつか懸念（下に添付の 3/9の meeting notes 参照）が出てきていたので、それを中心に議論しましょう。
>      >
>      >
>      > 3/9 の議論から出てきた JLReq TF フォント分科会のとりあえずのゴールは、「フォントとレイアウトエンジンとの間の問題点を明確化する」です。また、村田さんの言われるように、この二つのレイヤの間の責任分担を明確化すべきでしょう。どのように成果物にするのが良いですかね。プロセスをよく理解していないのですが、報告書を書いて、そのあとは？ > *下農さんかな？*
> 
>      まとまり方とか内容によるんじゃないかとは思いますが、、simple ruby的にi18n WG Noteに上げるのも
>     いいかもしれませんが、提案としてCSS WGとかに出すとかいろいろな方法もあり得るんじゃないかなという
>     気はします。WG Noteにしたとしても、どちらにせよいろんな方面にインプットや議論しないといけない内
>     容ですし、議論の展開次第なんじゃないかな？とは思っているところです。。はい。
> 
> 
>      > 木田
>      >
>      > 転送されたメッセージ:
>      >>
>      >> 差出人: 木田泰夫
>     <kida@me.com <mailto:kida@me.com> <mailto:kida@me.com <mailto:kida@me.com>>>
>      >> 日時: 2021年3月30日 19:11:31 JST
>      >> 宛先: JLReq TF 日本語 <public-i18n-japanese@w3.org <mailto:public-i18n-japanese@w3.org>>
>      >> 件名: フォント分科会 3/30
>      >>
>      >> JLReq TF の皆様、
>      >>
>      >> 今日のミーティングの記録をまとめました。修正点、足りない点などあれば教えてください。
>      >>
>      >>
>      >> 村田さん（二つ目は田嶋さんにも）に二点質問：
>      >> • プレゼンの P13 で、U であるべきなのに Tu なのは中国考慮、と書いてあるところがありますが、どのようなことなのか教えていただけますか？
>      >> • P3 オープンな環境、について。オープンとは言っても程度問題で、重要なケースから稀な組み合わせまで、広いスペクトラムがあると思います。例えば OS などに付属のみんな知っているフォント × よく使われるブラウザ（Safari, Chrome, Firefoxの三つ?）、OS 付属の EPUB リーダ、そして Amazon Kindle は最重要かと想像します。ここに挙げた、私に容易に想像のつく組み合わせ以外に、どのようなフォント and/or リーダーが重要ですか？
>      >>
>      >> 石井さんに質問（別スレッドで既に聞きましたが）：
>      >> • レイアウトエンジン、例えばウェブブラウザから、特定の文字に対して GSUB/verX があって、つまり横転するに違いない、ということを知ることは簡単ですか？ もしそれができれば、正立横転の「判断」をフォントに任せずに、ウェブブラウザから完全にコントロールできますか？
>      >>
>      >>
>      >> ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>      >> 今日のゴール：フォントとレイアウトエンジンとの間の問題点を明確化する
>      >>
>      >> 村田さんのプレゼン
>      >> https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=T6rdZB <https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=T6rdZB> <https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=T6rdZB <https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=T6rdZB>>
>      >>
>      >> 箱庭からオープンな環境へ
>      >> • 従来はコンテンツに対してフォントとアプリが決まったセットであった。印刷さえできれば良い。デジタルデータであっても、フォントとアプリが決まった組み合わせ
>      >> • 今のオープンな環境：どのブラウザ、どのフォント、どのEPUBリーダが使われるかわからない
>      >> 問題
>      >> • 縦書きにおいて、記号の一部、矢印などの正立回転の挙動が不統一
>      >> • 角川などは一文字づつ調査。危ないものはビットマップに置き換える。文字処理技術の敗北。アクセシビリティ問題
>      >> • 同じような問題は、他の言語でも起こっている。アラビア語の伸ばし処理、韓国語の約物、ヘブライ語、デヴァナガリなど
>      >> • CSS working group からフォントとの問題点がリエゾンステートメントとして SC29 に送られた（薛さんの2/14のメール）
>      >> 原因
>      >> • EPUB リーダの実装に問題がある
>      >> • 特に amazon の実装で問題が多い
>      >> • AJ1, CSS Writing mode (Browser), UAX50 がそれぞれ整合していない
>      >> • MS のメイリオとMS明朝で異なる。
>      >> • AJ1 フォントは AJ1 
テンプレートで揃っている。源ノ角は UAX50。TrueType はバラバラ
>      >> • また議論の中から、記号の誤用、または文字コードの定義がそもそも曖昧であるケースも見られた
>      >> 問題となる文字の例
>      >> • U+2016 Double Vertical Line
>      >> • U+3030 Wavy Dash
>      >> （あれ、悪いのは
>     MS 明朝だけでは？）
>      >>
>      >> 結論
>      >> • Adobe-Japan1 のテンプレート通りにフォントを作ると UAX50 に適合しない
>      >> • UAX50 に適合しても、CSS Writing Mode で横転してくれない文字がある（どれ？）
>      >> • フォントを直すと過去の資産が壊れる
>      >> • 問題解決にはまず現状分析が重要
>      >> –––––––
>      >> 議論
>      >> • 調査範囲を増やす必要がある（todo: 村田さん @ 文字情報なんたら委員会）
>      >> • フォントベンダーは問題についてあまり理解していないように見える（村田）
>      >> • Ken はずれがあるのは知っていて、AJ1 のテンプレートを無視すべき、と言っている
>      >> • Adobe からは UAX50 を変えるべきというフィードバック（Nat）
>      >> • AJ1 → UAX で一旦互換性を無視すべきという意見（石井）
>      >> • CSS 専用 vert ? 日本語用 UAX50?
>      >> • AJ1x, CSS Writing mode, UAX50 の違いの網羅的なリストはあるか？ Nat が社内向けに持っている（todo: Nat が文書をシェアする）
>      >> • それぞれの約物、記号の意味、用法、縦横の挙動を整理し直すべきではないか？（木田）
>      >>
>      >> 次回のフォント分科会は 4/20
>      >> 今回約物の半角ツメの問題について話す時間がなかったのでまずその話題から。それ以外に問題点はあるか？ メーリングリストで進められるものは進める。
>      >> ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>      >>
>      >>
>      >
>      >> 2021/03/09 13:06、木田泰夫 <kida@mac.com <mailto:kida@mac.com> <mailto:kida@mac.com <mailto:kida@mac.com>>>のメール:
>      >>
>      >> JLreq TF meeting notes 3/9
>      > …
>      >> *日本語組版に対するフォントの問題
>      >> *前回（2021/1/26）の議論：
>      >> ボックスの中のどこにグリフがあるのかは本来的にフォントのみが知っていることであるから、約物を半角につめる機能はフォントが持つべきであろうという議論。また問題点として、ユーザーの手元には古い仕様のフォントがあること、そもそもフォント間の仕様がバラバラであることの問題が指摘されていた。
>      >>
>      >> *今回の議論：
>      >> *chws は約物が連続する場合に半角を詰めてくれる。単一フォント単一サイズでの簡易的な組版に便利。問題点もあり、1) 文頭文末で働かない、2) サイズやフォントなどスタイルを跨ると動かない、3) 空け方や詰め方の調節をしたい場合には使えない、などの点が指摘された（Nat、村上）。この機能がゴールとする適応領域は簡易的な組版であろう。ゴールをはっきりさせることが重要。別な領域で障害や混乱の元にならないことが重要（小林）
>      >>
>      >> 応用範囲の広い低レベルの機能が必要との議論があった。例えば、無条件に半角に詰めて JIS X4051
>     や JLReq が前提としているような半角約物にするフィーチャー、など。根本的な問題は、フォントの中のどこにグリフがあるかわからないという点（Nat、村上）。
>      >>
>      >> フォントとエンジンによって動作がバラバラで困るという問題が指摘された。組版の精緻さの違いなら良いのだが、基本的な所で異なると例えばマルチプラットフォーム・マルチベンダな電子書籍の開発に困る。例えば縦書きの際の挙動など基本的なところでバラバラである。フォントとエンジンの役割を決める必要がある。Florian の提案あり（URL?）（村田、田嶋）。
>      >>
>      >> フォントの仕様について、現在 AdobeJapan-1 がある程度統一的な仕様の役割を果たしていて、多くの CID フォントは従っているが、TrueType フォントはバラバラ。また、AdobeJapan-1 が定めるのはグリフセットまでで、フィーチャーは Ken Lunde がAdobeのフォント SDK 用のデータを配布していた程度。つまり仕様的なものではない。この状態からもう一歩進めて、日本語フォントが守るべき何らかのガイドラインがあると良いのではないか（それによってフォントとエンジンの役割も見えてくるだろう）（木田）。文字情報技術促進協議会としても興味がある。関心のあるベンダーも多いので手伝えると思う（小林）（そっちの仕事だ！木田）。JLReq で問題点を明確化すれば、ガイドライン自身は別な組織が考えてくれるだろう（Nat）
>      >>
>      >> JLReq TF ではとりあえず、問題点を明確化するためのミーティングを開くことを提案する。石井さんに来ていただくのは重要（木田、小林）
>      >
> 
> 
> 
> -- 
> Regards,
> Makoto