jfonts_Topics

===========================================================

2007/04/06 JTC1/SC34専門委員会における鈴木の発表のメモ

以下では、TrueTypeフォントと言った場合、TrueType Openおよびsfnt OpenTypeを含む。また、Adobe CIDフォントと言った場合、CFF OpenTypeも含むが、CFF OpenTypeにおける文字符号コードポイント-Adobe CIDマッピング機能は除外して考える。

===========================================================
1. CJK TrueTypeフォントによるAdobe CIDグリフ集合のエミュレーション方法について

研究の背景
----------
オープンソースソフトウェアにおいて、印刷基盤は依然として(ホスト側での詳細実装の必要がない)PS/PDFベースである。しかし、近年のOSSデスクトップではフォント基盤はTrueTypeフォントである。
* TrueTypeフォントの公開インタフェースは文字符号であるので、文字符号コードポイントのみをよりどころにOSSでCJK文書を印字しようとすると縦書き字形、罫線類、さまざまな異体字が抜け落ちてしまい、実用に耐えない。
* CJKのデジタルドキュメントでは、文字符号のみでは(縦書き、異体字など)印字字形を決定することができない。
- Adobeの場合は字形集合(Adobe Character Collection)を定義し、字形に管理番号(Adobe CharacterID (Adobe CID))を付加することで、Adobe CIDを陽に指定すれば表示字形を決定できるようにした。Adobe CharacterCollectionは、デザイン差までは踏み込まない字形集合の定義と解釈されている。
- Microsoftの場合は文字符号コードポイントに加え、抽象的なレイアウト機能(OpenTypeタグ)を指定することでTrueTypeフォント内部のグリフを置換する仕組を導入した。
* Adobe CIDとCJK TrueTypeを比較すると、
Adobe CIDはフォント非依存の公開規格として定義されているのに
対し、CJK TrueTypeではレイアウト機能はフォント非依存の規格
であるもののグリフ置換によってどのような字形が得られるかは
フォント依存である。
* Adobe CIDによって指定される字形を、文字符号コードポイントとOpenTypeタグのペアに変換するアルゴリズムがあれば、課題が解決できる。

解決の方針
----------
* Adobe CIDは巨大な字形集合であるので、目視によってAdobe CID → 文字符号+OpenTypeタグの対応表を作成するのはメンテナンスコストが大きすぎて現実的ではない。
* 文字符号とAdobe CIDの対応づけの手がかりとしてAdobeが正規に提供している機械可読なデータベースは、CMapとToUnicodeマッピングテーブルの2つである
* この2つのデータベースの組み合わせでAdobe CID → 文字符号+OpenTypeタグの対応表を作成するアルゴリズムを提案した

提案手法の評価
--------------
* 提案手法の評価観点として以下の3つがある。
1. 提案手法により、従来手法(文字符号コードポイントのみでグリフを決定した場合)で欠けているグリフの何割が復旧できるか
2. 提案手法でのデータベース生成の時間がフォント読み込みをどの程度遅延させるか
3. 提案手法でのフォント読み込み遅延は文書レンダリングに対してどの程度の遅延となるか
* 評価1
台湾、中華人民共和国用のAdobe CIDは情報交換用文字符号における文字集合(字形の詳細に立ち入らない文字集合)であるので、従来手法で欠けているグリフの数はそれほど多くない。また、縦書きの字形を文字符号レベルで別のコードポイントとして扱うので、縦書き字形の問題もある程度回避されている。
よって、提案手法により改善はするが、大きな改善としては見えない。これに対し、日本と韓国用のAdobe CIDでは従来手法では縦書きのグリフが全て欠けており、提案手法によりフォントがサポートしている字形については全て復旧できる。また、日本用のAdobe CIDでは細かな表示字形の違いのために導入されていた字形があり従来手法では正しく表示できていたものは半分以下であったが、7割程度まで復旧できた。
* 評価2
従来手法でのフォント読み込み時間の4-5倍(従来手法は0.4秒未満であったのに対し、提案手法では2秒程度)に遅延する。
これはアルゴリズムが扱うデータベースファイルが大きいことと、アルゴリズムの実装を全てユーザ空間で動作するPostScriptで実装したためである(システム空間PostScriptでは1秒程度まで短縮できる)。これはアルゴリズム自身には問題はなく、ポータビリティと最適化のトレードオフで決まる。
* 評価3
JEITAのプリンタ機能テスト用データを用いて、モニタ表示(75dpi)から印刷(1200dpi)までのレンダリング所用時間を計測すると、もっとも処理時間の短いモニタ表示においても遅延時間は3%満であり、致命的なレベルではないと考える。

今後の課題
----------
* 本提案アルゴリズムでは、縦書き字形についてはCJK TrueTypeフォントの中に入っている字形であれば、正常に抽出できた。
しかし、異体字(たとえば、JIS90字形とJIS2004字形の差異)については同一文字コードでの代替表示になっており、正しく表現できていない。OpenTypeの異体字タグにより、より正確な復旧の可能性を検討すべきである。
* 中華人民共和国用のCIDに彝文字が導入されたが、一般の漢字フォントには入っていないので、PostScript規格のrearranged fontの実装が期待される。

追補
----
* 課題の1つである、OpenTypeの異体字タグにより、CIDによる字形指定をより忠実に反映させられないかを検討した。
* CMapとToUnicode表の組み合わせを見るだけでは、どの異体字タグを使うべきかははっきりしない。仕様書を目視してAdobe CID → 文字符号+OpenTypeタグの表をメンテナンスしなければならないが、そもそもCIDでの字形指定とマッチするOpenTypeタグがあるかどうかははっきりしない。
* Adobeにより導入された異体字タグは大まかに2つのグループにわけられる。
a. 参照規格が明示されているもの(jp78, jp83, jp90, jp04, hojo, nlck)
b. 参照規格が明示されていないもの(smpl, tnam, trad, expt)
このうち、グループaの利用可能性を検討する。
* OpenType規格を参照すると、グループaの異体字タグでも仕様が明確に定まっているわけではない。jp78, jp83は1個のグリフに対し、複数の候補がありえるので、処理系は字形選択メニューを返すことが望ましいとされる。jp78, jp90は文字コードの変換を含むので、旧字体の字形を新字体に変える機能になるのか、旧字体の字形をJIS78またはJIS90の例示字形に揃える機能になるのか、実装に依存すると思われる。
自動的なグリフ決定を期待すると、使用可能なタグが少ない(jp04,hojo, nlck)ので、効果が小さいと思われる。
* Adobe CID仕様書を参照すると、参照する字形がJIS97の異体字とされていたCIDがJIS2000の例示字体を参照するように変更されるなどの変更があり、仕様書の変更を目視で追従しなければならない。
* 以上2つの問題があり、OpenType異体字タグによるマッピング精度の向上には疑問がある。異体字タグを文字コードの変換は含めないようにする、また、字形参照を厳密にするなどの改善が期待される。

出席者からのコメント
--------------------

NECシステムテクノロジー佐藤様
OCFおよびレガシCMapにおけるJIS78準拠というのは、当社のメインフレーム系の印刷出力が(JIS83策定以前の観点での)JIS78準拠で出力していたので、その出力との互換性のために定義したものと思われます。濁点つき半角カナや、半角罫線記号なども互換性のために導入されたグリフだと思われます。
JIS78文字集合全体をそのまま出力することを目的としていたので、JIS78-JIS83の際の入れ換えがあった22文字だけ、字形やコードポイントを切り変えたり、JIS90字形で書いたテキストの中で数文字だけJIS78字形を使いたい、というような利用方法はあまり行われていないと思われます。

モリサワ冨田様
モリサワのOCFリュウミン書体はJIS83準拠ではあるが、Adobe-Japan1-4以前のPSフォント製品に対して、OCF Compatibility領域の字形が(現在の観点で)JIS78準拠であるとか、JIS83準拠であるとか論じるのは無理がある。また、PS和文フォントのOCF Compatibilityの領域の字形は(現在の観点で言えば)ある程度のデザインのゆれがあり、Adobe-Japan1-4以降、より厳密なJIS78字形やJIS83字形として導入されたCIDに対して、OCF Compatibility領域の字形と整合性がとれないので、グリフを重複させざるを得ない場合がある。具体的なフォントを指定せずに、CIDやOpenTypeタグで厳密な字形を指定しようというのは無理がある。
また、OpenTypeの異体字指定タグによって抽象的にJIS78, JIS83字形を指定するニーズも無いわけではないが、aaltタグによって使用中のフォントの全ての異体字を表示させて、目視によって選択するという使い方も広く行なわれている。このような使い方の場合は、そもそも字形を選択した際に「JIS78字形だから」という理由で選択しているわけではないので、同一の異体字タグでアクセスしているからといって他のフォントで代替表示して良いという保証はない。このことからも、やはり、具体的なフォントを指定せずに厳密な字形を指定できる筈という考え方には無理がある。

リコー豆腐谷様
当社の場合、JIS X 0208文字集のフォント資産はJIS78とJIS83がまじったような状態なので、現在の観点でJIS78やJIS83、JIS90の例示字体への準拠を要求されると大量のグリフの作り直しが必要であり、また、既存の資産とのマッチングがとれず、書体設計のレベルで無理な要求であると思う。

===========================================================
2. Unicode異体字データベース(UTS#37)に対するAdobeからの
Adobe-Japan1提案について

2007年3月15日に公開レビュー締切となった、UnicodeへのAdobeからの異体字データベースおよび異体字タグ提案について、鈴木による内容分析と問題点の報告を行なった。

* Unicode異体字データベースは、各登録間での字形の重複などの可能性は関知しない。また、一つの登録内容の中で、字形が全て識別できるよう定義されているかについても関知しない。
* Adobe-Japan1異体字集合は、Adobe-Japan1-6から漢字以外のもの(ローマ字、かな、記号、組み文字)を除外したもの。
* 異体字データベースは各コードポイントに対する字形として整理されているのではなく、無名のグリフ集合である。Adobe TechNote#5078が附属書となっており、この中でグリフの由来が述べられているが、附属書の内容は審議対象ではないので、異体字データベースには含まれない。従って、Adobe TechNote #5078の内容によって抽象的に定義される内容(たとえば、OCF Compatibility領域のCIDがJIS90例示字形に準拠していることなど)はUnicodeの異体字データベースには入っていないと考えるべきである。
* Unicode異体字データベースおよび異体字タグはCJK統合漢字に対するもので、ドキュメントに含まれるCIDをCJK統合漢字とUnicode異体字の組み合わせで表現すると、従来のワークフローではCJK互換漢字を意図していたものがCJK統合漢字へ正規化されてしまう可能性がある。JIS2000, JIS2004ではCJK互換漢字のコードポイントをUnicodeにおける正式な表現としている文字があるため、この異体字タグとJIS2000, JIS2004の両立は難しいかもしれない。

出席者からのコメント
--------------------
大阪工大小町様
* 文字符号に関する議論はSC34/WG2が扱う範囲とずれるので、議論の場としてはあまり適切ではない。
* MPEG4のグループでOpenTypeのfont formatについて、そのままISO化を進めているが、タグの規格がないと実際にはOpenTypeのレイアウト機能は規格の枠内では使えないということを見落しているように思われる。文書を扱う規格としては、各タグがどのような機能を持つかについても踏み込まなければならないかもしれない。

GLOCOM 上村様
* ISO 10036での字形登録でも、字形の重複について判断すべきかどうか議論があったが、それについては登録者に任せることとした。
結局Unicodeにおいてもそのような落としどころにせざるを得ないのだと思う。Unicodeでは、基本面(BMP)への文字収録について「早いもの勝ち」の側面があったが、異体字の扱いについてはそのような問題はないのか?
(鈴木の回答: CJK統合漢字のコードポイント1個につき16ビット64k個のバリエーションが持てることもあり、現時点ではまだ問題視されていないと思う。)
===========================================================