Re: フォント分科会

# 五月雨式にすみません

フォントとレイアウトエンジンの契約の混乱という意味で、ラテン文字のイタリックのケースが解決の一つの参考になるかもしれないと思いつきました。イタリックの指定があった場合、もしフォントがイタリックを持っていればそれが使われます。が、そうでない場合、web ではむりくり oblique を作りますよね。もちろん高品質な結果にはならないんですが、なんとかそれで意図は伝わる、と。

これを日本語縦書きに適用すると、1) 各々の文字が縦書きでどの向きになるべきかの共有された合意があり、レイアウトエンジンはそれを知っている。2) 各々のグリフについて、フォントがそれを合意された向きにしてくれるかをエンジン側で知る手段がある。この二つが満たされれば、フォントの品質がバラバラでも縦横問題はなんとかなる？

文字によってはフォントがやってくれないとどうしようもないものもありますが、その必須部分は「日本語フォント」の必要最小限の定義にする。

木田

> 2021/03/30 8:31、木田泰夫 <kida@mac.com>のメール:
> 
> 村田さんにはぜひこのミーティングをリードしていただきたく。
> 
> 村田さん田嶋さんが提起していただいた縦書き時の記号の問題（とまとめて良いのですよね？）は、調査が進行中なんでしたっけ？ 以前にフォントとエンジンの組み合わせのチャートを見せていただいたような。
> 
> 違った問題として、議論のきっかけとなった、グリフに含まれている約物のアキを詰める件がありますね。
> 
> 他に、まだ触れられていない問題はあるでしょうか？
> 
> 木田
> 
>> 2021/03/30 1:19、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール:
>> 
>> >（そっちの仕事だ！木田）
>> 
>> 魂の叫び
>> 
>> 
>> マコト
>> 
>> 
>> 2021年3月29日(月) 23:07 木田泰夫 <kida@mac.com>:
>>> JLReq TF の皆様、
>>> 
>>> いよいよ明日（or 読まれた時間によっては、もしくはタイムゾーンによっては今日）、日本時間の火曜日30日10時からミーティングです。zoom のリンクは今朝早くに下農さんが送ってくれました。
>>> 
>>> 今回のミーティングではまず「フォントと組版ソフトウェアの役割が明確でないことから来る問題点を明確化」したいと思います。村田さんおよび田嶋さんより、縦書きにおける記号の挙動の問題が指摘されています。これについて、また他にどのような問題があるか、もしくは問題が考えられるかを確認したいと思います。
>>> 
>>> その作業が早めに終われば、それを受けてフォントと組版ソフトウェアの、村田さんの言葉によれば「契約」はどのようなものになるかのディスカッションができるかと思います。
>>> 
>>> 究極的には、このような議論が端緒となって、この場でか他の場でかは問いませんが、JLReq ならぬ、J Font Req のようなものができて、日本語フォントには何が期待されるのか、が明確化されると良いですね。
>>> 
>>> 
>>> ミーティングの前に、このメールの下に添付した内容、および村田さんからのプレゼン資料を読んでおいていただけると助かります。ここをスタートポイントにしようと思います。
>>> 
>>> https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=T6rdZB

>>> 
>>> 
>>> See you all in 11 hours!
>>> 
>>> 木田
>>> 
>>> ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>>>> 2021/03/14 15:44、MURATA <eb2mmrt@gmail.com>のメール:
>>> 
>>> 皆さん、
>>> 
>>> フォントとCSSの契約という点から、縦書きにおける
>>> 文字横転について書いたものです。
>>> 
>>> https://1drv.ms/p/s!An5Z79wj5AZBgrp06H7M3ZUfkyQ4AA?e=T6rdZB

>>> 
>>> 村田 真
>>> 
>>> ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>>>> 2021/03/11 16:11、田嶋　淳 <tajima@sanyosha.co.jp>のメール:
>>> 
>>> みなさま
>>> 
>>> 　異論はないですが、現場の立場からの補足として、フォントの挙動でEPUB制作側として一番困るのは「挙動が統一されておらず、閲覧者が表示フォントを切り替えたら内容の意味合いが変わってしまうこと」です。意味合いが変わってしまう典型的な例としては、例えば矢印「→」の縦書き時の向きが90度回ってしまう、などがあり、これは実際一部のTrueTypeフォントからAJ1準拠のフォントに変えた際に向きが変わるのを経験しています。
>>> 　こういったフォントごとの振る舞いの違いは、DTP等で紙を最終出力先とする場合にはあまり問題になりませんでしたが、WebやEPUB等では大きな問題になる可能性があるものと思います。何らかの基準を設けての統一を望みます。
>>> 
>>> ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>>>> 2021/03/11 15:37、MURATA <eb2mmrt@gmail.com>のメール:
>>> みなさん、
>>> 
>>> この前、口頭で話したことを書いてみました。あとで、
>>> CITPCJの資料もお送りします。
>>> 
>>> フォントと表示アプリの間の関係を整理し、きちんとした
>>> 原則を立てるべきだと私は考えています。そうでないと、
>>> オープンなモバイル環境での文書交換に対処できないと思
>>> います。
>>> 
>>> 現状: フォントが提供するGSUBなどはただのヒントでしか
>>> ない。つまり、フォントはGSUBなどを提供する義務はな
>>> い。提供されていても表示アプリにはそれを尊重する義務
>>> はない。
>>> 
>>> フォント提供側からすると、表示アプリによってどの情報
>>> が使われ、どの情報が無視されるかは分からない。
>>> 
>>> 表示アプリ側からすると、どの情報がフォントの一部として
>>> 提供され、どれが提供されないかは分からない。
>>> 
>>> これまで何とかなったのは二つの理由による。
>>> 
>>> - オープンな文書交換をしない（表示アプリもフォントも決め打
>>>   ちでき、他での再生は考えなくてもよかった）。
>>> 
>>> - AJ1が規範として機能してきた。
>>> 
>>> 問題点
>>> 
>>> モバイルでの文書交換が頻発する今日では、どの表示アプリ
>>> が用いられ、どのフォントが使われるかはその場になって
>>> みないとわからない。とくに、AJ1フォントになるのか、
>>> TrueTypeフォントになるのかわからない。
>>> 
>>> こうした変化によって問題が顕在化してきた。日本語EPUB
>>> だと、どの文字が寝るのか、どの文字が正立するのかは、
>>> やってみないとわからない（文字情報技術推進協議会で調
>>> 査中）。
>>> 
>>> EPUB文書作成側は画像埋め込みによって問題に対処してきた
>>> （アクセシビリティ最悪）。
>>> 
>>> 縦書き年賀状アプリには、文字コードを使うことをきっぱ
>>> り諦めてグリフIDを直接使うものすらある。
>>> 
>>> あるべき姿（村田意見）:
>>> 
>>> フォントと表示アプリの間の契約を確立すべき。
>>> 
>>> フォントは何を指定しないといけないかが決まっている。
>>> その義務を果たさないフォントは適合しないものとして扱
>>> う（存在を認めないと言っているのではなく、普通の契約
>>> に従わないからオープンなモバイル環境での文書交換に使
>>> えないというだけ）。
>>> 
>>> 表示アプリは、フォントが提供するものを尊重しなければ
>>> ならないことが決まっている。（尊重しないものは、普通
>>> の契約に従わないのでオープンなモバイル環境での文書交
>>> 換に使えない）。
>>> 
>>> 全部が全部ガチガチにはできないとは思いますが、少し
>>> ずつ義務化がされていくべきと思います。CSS Writing
>>> Modesも、vertを使うこと(the OpenType vert feature 
>>> must be enabled)と書かれています。
>>> 
>>> ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
>>>> 2021/03/09 13:06、木田泰夫 <kida@mac.com>のメール:
>>> 
>>> 日本語組版に対するフォントの問題
>>> 前回（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