Re: アドビさんよりの資料（フォント分科会 AJ1 と UAX#50 の問題）

「As a fallback」は、２つの意味を含みます。

   1. 技術的に可能であれば、アプリケーションがfallbackを実装してもよい。
   2.
   アプリケーションがfallbackを実装するかもしれないし、実装しないかもしれない、という想定の元、どちらのアプリケーションでも同じ向きが表示できるフォントを実装するべきである

後者によって、フォント内部のグリフの向きが規定されることになります。

階層的には、Unicodeがあり、それを参照するOpenTypeがあり、両者を参照するCSSがあります。なので、Unicodeは特定のフォントファイルのフォーマットやアプリケーションを想定しません。このため、UAX#50は「vertがかかったかどうかを確認可能かどうか」には依存していません。

CSSは、OpenTypeを想定して規定しているため、fallbackは実装せずに、U/Tu/Trは同じ向きで表示する
<https://drafts.csswg.org/css-writing-modes-3/#vertical-orientations>
ように規定しています。上記２を満たしているフォントであれば、アプリ側の想定とフォントが持っているグリフの向きが合致するため、期待通りの結果となりますが、そうでないフォントでは期待通りの結果にはなりません。この点がここで懸念されている「UAX#50フォントでない場合に、向きを制御できない」という点ですよね。

Natからも指摘がありましたが、グリフの中のデータを解析すれば、向きを認識することは可能だと思います。より高い機能を目指すアプリケーションがそういう機能を実装することは良いことだと思います。
UAX#50は、そのようなアプリケーション実装を許容しています。

CSSは、ブラウザーやプラットフォームでの実装を想定し、相互運用性を重視しているため

   1. UAX#50対応フォントでは、コンテンツ制作者が向きを制御できる
   2. UAX#50対応ではないフォントでも、同じフォントであれば、ブラウザーによって違いが出ないようにする（fallback実装を禁止している）
   3. UAX#50対応ではないフォントでは、コンテンツ制作者が向きの制御をすることは断念する

という方針のもとに規定されています。これは、特に上記３は、フォントを作る人たちが、将来的にUAX#50に対応する、という前提が必須で、そのために、当時としては少なくともOpenTypeやUnicodeに参加しているフォントベンダーが将来的にフォントを改変することに合意したものとして、規定されました。

もちろん「できると思っていたが、やってみたらできなかった」ということはあるので、より多くのCJKフォントベンダーが議論に加わった段階で、フォントベンダーが「過去互換を壊してvertをUAX#50対応に改変することは不可能だった」という結論に至ることは、十分に有り得ると思います。

その場合にはどうするべきか。フォントのvertの過去互換が必須となったのであれば、前提条件が一つ変わったということですから、それを踏まえて再議論と仕様変更をする、という話だと思うので、OpenTypeとCSS
WGに上げる、というのが第一段階としてはいいのではないでしょうか。

相互運用性がない状況においては、過去互換と相互運用性は両立しないと思うので、「現在のフォントそのままで、過去互換と向きの制御と相互運用性の全てを担保する」というのは技術的に困難だと思いますが、例えば「過去互換を保持しつつ、向きの制御と相互運用性も提供できるフォントを作れる仕様にする」ようなことは、技術的には可能だと思います。どのような案に至るかはWG次第ですが、フォントベンダーから見て、どれは担保したいことで、どれは改変・譲歩できることなのか、というのが明確になれば、議論も進みやすいかと思います。

On Fri, Jun 18, 2021 at 7:22 AM 木田泰夫 <kida@mac.com> wrote:

> お、なるほど。U/Tu/Tr のコードポイントはフォントに自由度がある。R
> のコードポイントも同様だが、回転はアプリケーションに任せる。ということですね。
>
> Tu/Tr の “as a fallback” ってどう言う風なケースに使うんですか？
> フォントがやってくれないと判断したらアプリケーションがすると言う意味であると思っていたのですが、vert
> がかかったかどうかわからないならこの解釈は間違いですかね。
>
> 木田
>
> 2021/06/17 23:14、Koji Ishii <kojii@chromium.org>のメール:
>
>
> Uのコードポイントに対して、向きを保持したまま字形を変えることについては、禁止する規定はないはずですし、CSSでもvertをオンにしますから、問題ありません。
>
> On Thu, Jun 17, 2021 at 10:19 PM 木田泰夫 <kida@mac.com> wrote:
>
>> 石井さん、
>>
>> 理解です。その設計ではフォント側に例えば縦書きと横書きで仮名の形を調整するなどの自由度はないことになりますかね？
>>
>> 木田
>>
>> 2021/06/16 11:31、Koji Ishii <kojii@chromium.org>のメール:
>>
>> 昨日ミーティングでしたよね、すみません、寝過ごしました。。。
>>
>> そもそも、アプリケーションはあるグリフに関して、フォントが vert を持っていて縦横既にひっくり返したかどうか知っているんでしょうか？
>>
>>
>> 技術的には、これを知ることはできません。厳密には、vertがグリフを置き換えたかどうかを知ることは可能ですが、複数のfeatureがあたった時など、いろいろと複雑なため、現存するShaping
>> Engineはその情報をアプリに渡しません。グリフを置き換えたかどうかを知ることができても、
>> 向きが回転していないグリフに置き換える場合もあるため、そのグリフの実際の向きは不明です。
>>
>> UAX#50の設計思想としては
>> 4 Glyphs Changes for Vertical Orientation
>> <http://unicode.org/reports/tr50/#vertical_alternates>
>> がそれを知るためのフォントとアプリの間の契約で、そのために、UAX#50互換でないフォントでは正確な指示ができない、という制限事項に繋がります。
>>
>> On Tue, Jun 15, 2021 at 10:04 AM 木田泰夫 <kida@mac.com> wrote:
>>
>>> 太郎さんミーティングーーー
>>>
>>> 2021/06/15 10:02、Taro Yamamoto <tyamamot@adobe.com>のメール:
>>>
>>> 木田さん、
>>>
>>>
>>>    - Category 2: 縦横字形が異なりかつ90度回転の関係ではないとフォントが考える字 Tu/Tr
>>>
>>>
>>>
>>> ここには、図像の回転が全角の中心で行われることを保証するためにvertに含めているものがあるかもしれません。
>>>
>>> Uの文字に対してvertが割り当てられていて、そのグリフを使った結果も同じ正立の場合は、デザイン上の縦と横の差異のためにvert
>>> が割り当てられている場合があります。
>>>
>>> Category 7: 縦横字形が90度回転の関係なのでアプリケーションが横倒しすることをフォントが期待 R
>>>
>>>                      フォント側は何もしていないので、期待もしていませんが、これは主にプロポーショナルのラテン文字です。
>>>
>>> Category 8: 縦横字形が同じ U
>>>
>>>                      これは問題なしです。
>>>
>>> > 2. ある文字が Tu/Tr であるか R であるかは固定で定められていて、フォントに自由度はない
>>>
>>> vertが示すグリフの姿勢がUAX #50の姿勢の「見え」に等しい場合には、vert
>>> がある場合には、フォント側のグリフを使ってもらわないと、困ると思います。これは、Uの場合はデザイン上の差異があるためと、R
>>> の場合に、上記の全角中心での回転が保証されない場合は、vertでやらせてもらいます、ということになるのではと感じます。
>>>
>>> --Taro
>>>
>>>
>>> 木田
>>>
>>>
>>> 2021/06/11 22:30、木田泰夫 <kida@mac.com>のメール:
>>>
>>> JLReq TF （フォント分科会）の皆様、
>>>
>>> 15日火曜日のミーティングに向けて、アドビさんから縦書き字形の AJ1 と UAX #50
>>> の問題点を調査した報告書をいただきました。シェアする許可をいただきましたので、転送します。
>>>
>>> ミーティングまでに消化しておいていただけると助かります。
>>>
>>> 下のファイルが要約で、他のファイルはそこから参照されるデータです。
>>>
>>> UAX50に関する調査中間報告v1.1.pdf
>>>
>>>
>>> 詳しくは下の山本さんの説明を読んでください。
>>>
>>> 木田
>>>
>>>
>>> 木田様、
>>>
>>>
>>> いつもお世話になります。アドビの山本太郎です。
>>> Nat McCullyからお知らせしているかとは思いますが、私が作成したUAX #50
>>> 関連の中間報告（要約）とその関連資料を下記のリンクからダウンロードしてご参照ください。
>>>
>>> https://shared-assets.adobe.com/link/2bc2d484-52e3-4381-6ed0-147fda604563

>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshared-assets.adobe.com%2Flink%2F2bc2d484-52e3-4381-6ed0-147fda604563&data=04%7C01%7Ctyamamot%40adobe.com%7C4eeafc9774cd4996e26d08d92f95b5bd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637593142311929902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BmAb1e1LsbnlA%2Bhlyjo7c9DAP6IMUAY9TVUtHi8%2FzGk%3D&reserved=0>
>>>
>>>
>>> ZIPファイルには下記のファイルが含まれています。
>>>
>>>
>>> 0                UAX50に関する調査中間報告v1.1.pdf
>>> 1                SummaryUTR50issue1.3.pdf
>>> 2                VERT_List_m
>>> 3                IDUAX50DiscrepancyV031LqOff.pdf
>>>
>>>
>>> 4                SHSvertlist3_fixed.pdf
>>>
>>> 0のPDFファイルが主な要約となります。1, 2, 3はその要約が参照するものです。
>>>
>>> 上記の0–3は、Adobe-Japan1-7のグリフ集合に準拠した小塚明朝Pr6NフォントのGSUBテーブルのvert
>>> フィーチャーについて調べた内容（0の前半）と同じフォントをInDesignで使用した場合の挙動について調べたもの（0の後半）の要約です。
>>>
>>> それとは別に、4は、Pan-CJKフォントの源ノ角ゴシック（Source Han Sans）のフォントのGSUBテーブルのvert
>>> フィーチャーをプロットしたもので、上記1のPDFの後半の説明と関連しています。ただし、源ノ角ゴシックについては、GSUBのvert
>>> フィーチャーを調べた段階で、まだInDesign等のアプリケーションの動作との関連は詳しくは調べていません。
>>>
>>> 取り急ぎ、資料の送付まで。
>>> よろしくお願いいたします。
>>>
>>> 山本太郎
>>> アドビ
>>>
>>>
>>>
>>
>