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

田嶋さん、すごくいいフィードバックをありがとうございます。

実は昨日は、短い説明版と長い説明版を考えていたのですが、残り時間を見て、短い版をお話ししました。それで少し誤解を招いたようです、すみません。少し補足させてください。

実装の検討の中で、三つの方法を検討しました。
１．haltを使う方法
２．chwsを使う方法
３．アプリ側で計算する方法
それぞれ特性が異なり、組み合わせも可能です。ブラウザーやOSなどの速度を強く要求される実装は、１と２を組み合わせるのがよいと考えておりまして、これをお話ししました。これで実装した場合、実装そのものはすぐ終わるのですが、利用されるすべてのフォントにhaltとchwsが追加されないと、すべてのユーザーが利用することができません。対応フォントが普及する期間を、大雑把に10～20年と表現しました。

おっしゃるように、要求事項の異なるアプリや、特定のフォントしか使わないアプリでは、もっと短い期間で実装が可能です。MS
Wordでは、フォントの実装を待たず、両端揃えの優先度も対応するため、３のみで実装して、数か月で実装を終わらせました。EPUBリーダーのように数個のフォントしか使わない環境で、フォントがhaltとchwsを持っていてくれていれば、１と２の組み合わせで、数日で実装が終わると思います。

先日、Koboの友人と話した際にこの話をしたら、「１と２の組み合わせを数日で」に興味を持ってもらったのですが、フォローを忘れていましたのを思い出しました。また連絡したいと思います。ありがとうございます。

もし、アプリやフォントの実装をされている方で、早い実装にご興味がある方がいらしたら、ぜひ直接メールしてください。JLTFは仕様の話が中心だと思ったので結果だけ短くお話ししましたが、アプリあるいはフォントの実装にご興味のある方がいらっしゃれば、うちで検討した内容や手法をもっと詳しくお話しできます。

よろしくお願いします。

On Wed, Apr 21, 2021 at 12:05 PM 田嶋 淳 <tajima@sanyosha.co.jp> wrote:

> 木田さま
> みなさま
>
>
> 昨日聞かせていただいての感想的なものなのですが、OSやブラウザデフォルトレベルで日本語組版を正しく処理するのにはフォントを含めた最適化が必要でそれには10〜20年かかる、というのはよくわかったのですが、例えばEPUBのビューアのようなもっと小さな環境向けに「こういう処理が望ましい」という指針があればユーザーはその中ではいち早く最適化のメリットを享受できるのかな、と。その範囲なら使用されるフォントも絞り込めますし処理速度も問題にはならなさそうです。まあhontoやKinoppyなどの日本向けRSは既にやっていることですし、そのためにあるのがJLREQだと言われればその通りなのですが。
>
> 2021/04/20 12:18、木田泰夫 <kida@mac.com>のメール:
>
> 村田さんの分をなんとかカバーしました！
>
> 木田
>
> 2021/04/20 11:52、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール:
>
> みなさん、
>
> 申し訳ありません。最初の部分は出るつもりだったの
> ですが、出られませんでした。すみません。
>
> 村田 真
>
> 2021年4月18日(日) 11:46 木田泰夫 <kida@mac.com>:
>
>> JLreq TF の皆さま、
>>
>> フォント分科会が明後日 4/20 10:00 からです。
>>
>> 今回の議題は半角ツメの問題です。石井さん提案の OpenType テーブルを中心にした話題になるかと思います。まず石井さんに説明をしていただいて（
>> *石井さん、お願いできますか？*）、いくつか懸念（下に添付の 3/9の meeting notes
>> 参照）が出てきていたので、それを中心に議論しましょう。
>>
>>
>> 3/9 の議論から出てきた JLReq TF
>> フォント分科会のとりあえずのゴールは、「フォントとレイアウトエンジンとの間の問題点を明確化する」です。また、村田さんの言われるように、この二つのレイヤの間の責任分担を明確化すべきでしょう。どのように成果物にするのが良いですかね。プロセスをよく理解していないのですが、報告書を書いて、そのあとは？
>> > *下農さんかな？*
>>
>> 木田
>>
>> 転送されたメッセージ:
>>
>>
>> 差出人: 木田泰夫 <kida@me.com>
>> 日時: 2021年3月30日 19:11:31 JST
>> 宛先: JLReq TF 日本語 <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

>>
>> 箱庭からオープンな環境へ
>> •
>> 従来はコンテンツに対してフォントとアプリが決まったセットであった。印刷さえできれば良い。デジタルデータであっても、フォントとアプリが決まった組み合わせ
>> • 今のオープンな環境：どのブラウザ、どのフォント、どの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>のメール:
>>
>> 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
>
>
>
> ***************************************
> （株）三陽社
> メディア開発室
> http://www.sanyosha.co.jp/

>
> 田嶋 淳
> tajima@sanyosha.co.jp
>
> ※ブログ運営中です。
> ご意見をいただければ幸いです。
> http://densyodamasii.com/

> ***************************************
>
>