第 2 回 文字情報基盤技術検討 WG
議事録
1.
日時
平成 23 年 9 月 2 日（金）15：00～17：002.
場所
IPA 13 階会議室 C3.
出席者
【委員長】 藤沢 淳 キヤノン株式会社ソフトウェア応用第二開発部 部長 W3C SVG WG メンバー EXI WG メンバー 【委員】 加藤 誠 一般財団法人 Mozilla Japan テクニカルアドバイザ 河合 孝志 株式会社日立製作所 公共システム事業部全国公共ソリューション本部 自治体アプリケーション第二部 課長 【事務局】 田代 秀一 独立行政法人情報処理推進機構 国際標準推進センター長 小林 龍生 独立行政法人情報処理推進機構 国際標準推進センター専門委員 沼田 秀穂 独立行政法人情報処理推進機構 国際標準推進センター研究員 池田 佳代 独立行政法人情報処理推進機構 国際標準推進センター研究員4.
配布資料
＜配布資料＞ 資料１：委員名簿 資料２：第 1 回文字情報基盤技術検討 WG 議事録5.
議事内容
1. 開会 田代センター長より開会の挨拶。 2. 前回議事録確認 対象端末について 実証実験の対象端末の範囲はどのように考えているのか？ 総務省の予算項目には、次世代ブラウザの開発というのが入るとのことである。総務 省は、通信・放送を所管するため、この次世代ブラウザの対象は、PC だけではなくテ レビや携帯電話等も含まれている。このような端末のブラウザから電子行政へのアク セス等も考えられるので、検討する必要がある。 では、今回の実証実験は、そのようなテレビやスマートフォントのブラウザも対象と して考えているの？ 現時点では、対象端末について白紙である。しかし、スマートフォンは考慮すべきで ある。 1 PC は、技術的に先行しているが、スマートフォンは PC に比べると遅れがある。現状 のスマートフォントを対象に加えてしまうと、実証実験後の１年、２年経つと状況が かなり変わっていることが想定される。スマートフォンが先行している PC に追いつ てくることも考えられる。 今のスマートフォン端末は、PC と比較すると明らかな制限があることが分かっている ので、この状況を踏まえて実証実験を行うのは難しいのではないか。 スマートフォントの Web が PC のブラウザに追いつくまでに、Android 2.3 だと１年 半くらい、Apple 社であれば大体１年くらいのタイムラグがある。 では、まとめると、数年後にはスマートフォンが PC に対する遅れをキャッチアップ することを想定し、実証実験の対象端末は PC を行うことにするが、PC だけで動けば よいということではないと考えるスタンスで進めるということになる。 まず PC で動くように実験を進め、その状態でスマートフォンがアクセスするとどの ようになるのか？というところで問題点をまとめることが第一段階ではないだろうか。 また、実証実験の期間を考慮すると端末種が増えると評価が難しくなる恐れがある。 符号化について
「IVS も含めて Unicode で符号化されている文字は、Unicode で扱い、符号外文字 についてはインライン図形で」となっているが、本当にそれで問題はないのか。 その場合、実証実験に参加する人は IPAmj 明朝をインストール必要ということになる。 逆に言えば、「IVS も含めて Unicode で符号化されている文字は、実用段階にある。」 ということを実証する考えでよいか。 結果的にそういうことになる。IVS が正しく表示されるということを実証することな る。 しかし、現状での IVS 対応は、実装レベルで言えば思ったほど進んでいないように思 われる。 PC で考えた場合に、ブラウザでの表示に限定すれば IVS の表示は問題ない。 それは本当だろうか？ ブラウザ自体でレンダリングする場合は問題ない。 IVS を使った場合に、カット＆ペーストを行うとどうなるのかという問題がでてくる。 そうではあるが、IVS も含めた文字コードで実証実験を行うべきかは、よく考えなけ ればならない。 実証実験の視点は二つある。一つは、技術的な視点。もう一つは社会に受け入れられ るかという点である。 実証実験のフォーカスであるが、実運用ではなく実証実験であるため、問題点を洗い 出すことも重要である。テスト範囲も明示した上で、課題を整理し報告書作成の際に まとめることで次の実証実験につなげていくようにすべきである。 W3C では、IVS を利用することはアーキテクチャとして合意されている。しかし、 HTML や CSS における IVS の扱いはまだ決まっていない。 CSS WG では、IVS についてポジティブな意見があまりないと聞いている。 2
HTTP では、IVS を通信できることになっているが、それ以外は具体的決まっていな いということか。 IVS は、あくまで UTF-8 の一部（キャラクター）であるので HTTP における課題は得 にないが、Web の話になると、Web フォント等の話題があるため、コードをどう扱 うかが問題となる。 WEB で扱うコンテンツとして、文字のエンコーディングとしてどのようなものである べきかという中で、ノーマライゼーションはどうすべきか？ということなどが揺れて いる。 W3C が規格を「どう読むか」よりも「どう運用するか」ということの動向が重要となっ てくる。 CSS WG の話題では、文字を入れ替える、装飾するといったことを考慮しなければな らないので、文字を一つの集合体としての認識でどう扱う、規格をどのように運用す るかという話になる。html はそのまま扱うことができるが、JavaScript は、UTF-16 であるため、文字が分離されてしまう。 符号化されている文字は IVS も含めて、実証実験では扱っていくこととする。 コピー&ペーストについて 資料 2 の実証実験要件（案）を見ると、コピー＆ペーストをした場合に、最低限の文 字情報の交換を保証することと記載されているが、前回の議事ではこのようにまと まったのか。 文字がインライン図形で表示されている場合に、コピー&ペーストを行うと、MJ 文字 図形名をカットバッファーに格納できるようにするのが、実証実験の要件である。 コピー&ペーストした文字は、どのような文字になるべきだとか、MJ 文字図形名を示 す文字列になるべきだというのがあるのか。 符号化外文字が文字については、MJ 文字図形名になるべきであると考えている。 符号化されていない文字であっても、必ずしも MJ 文字図形名ではなく、それに代わ る文字であるとか、資料 2 にはゲタ「〓」のっているが、何等かの文字を表示すると いったことについての可能性はどうだったのか。 我々としては、MJ 文字図形名が表示された方が、分かりやすいと考えている。Img タグの Alt 属性に情報を入れることが可能であり、絵文字等では一般的である。多く の SNS では、このような手法が用いられているため、このような形式を利用するのは どうかという議論をしていただいた。 Img タグを使用した場合に、Alt 情報をフィッシングに利用されるので、注意しなけれ ばならないと意見が出た。特定目的では良いが、一般目的のユーザが使用すると危険 な場合等もあるようだ。このようなことについて、議論を行っていきたい。 インライン図形の表示やタグ情報のコピーは問題ないが、どのよう方法が標準やセ キュリティの面から望ましいのか、この場で議論を行いたい。 コピーした時の規格や定義がないので、ブラウザに依存する。 HTML には文字参照(&XXXX;)があるが、定義されていれば文字が表示され、そうで 3
ないと文字列がそのまま表示されるものだが、この手法を利用してユーザが MJ 文字 図形名を目にするというのも良いのではないか。 キャラクターリファレンスは、はじめから定義されているのか。 キャラクターリファレンスは、あらかじめ定義されている。仕組みとしては、パーサー が、リプレースしているだけである。 一般的なものではあれば、キャラクターリファレンスは HTML の dtd で定義されてい る。実情としては、dtd を読み込んで解釈しているのではなく、規格として定義され ているので、ブラウザ側であらかじめ用意している。 一般的には、ブラウザは把握できないが、アドインのようにすることで解釈すること ができるということは可能か。 それは正規化のルールを用意すれば実現可能であると思われる。 キャラクターリファレンスの場合、ユーザ側はやはり置換される文字のフォントも 持っているのか。例えば、áの場合は、á がレンダリングされる。 キャラクターリファレンスの場合、その文字列から Unicode に変換して、コードポイ ントの文字を表示している。 では、IVS も含めてキャラクターリファレンスは利用できるが、符号化外文字につい ては扱うことができないということか。 カットバッファーに格納されるものについて、動きはないのか？ セキュリティの話がからむと、難しい問題となる。コピーで格納されるときに問題と なる。クリップボードを勝手に参照して、情報を送りつける等の操作が可能となって しまう。 インライン図形について 前回の議事録を確認すると、インライン図形は SVG のファイルを HTML の Img タグ で表示するというイメージか？ それは、議題の焦点の一つであったが、委員長不在だったため議論が進んでいない。 今回でスケーラブルな表示がしたいというのは要件であるのか？ ビットマップを複数のサイズを用意して切り替えて使うという方法もあるので、かな らずしもアウトラインでなければならいというわけではない。 逆に、どのファイルフォーマットが適切なのかということを実験してみたいと考えて いる。 SVG フォントもメリットがある。SVG であってもグラフィックの場合は、あくまで グラフィックであるため、文字列として選択するとか、アンダーラインを引くといっ た装飾など、文字としての振舞いができなくなる。SVG フォントの場合は、フォント と画像との間として、よい落としどころになるので、それも含めて検討したい。 SVG フォントについては、ブラウザの対応が厳しいのではないか。 ただ新しい動きがでてきている。OpenType に SVG フォントを入れるという議論が なされている。OpenType にしても、Web フォントの WOFF にしても、その中身と いうのは、TrueType のフォントである。つまり、フォントのフォーマットは同じで
あり、コンテナが異なるだけである。SVG フォントは、SVG の描画機能が利用でき るため魅力があるが、コンテナとしては全く魅力がなかった。コンテナとしては、 OpenType や WOFF を利用し、その中に TrueType のストラクチャーとして SVG を 入れるというメリットがあるのではないかというものである。例えば、絵文字は色が 含まれていたりアニメーションがあったりするので、これを SVG にし、OpenType に格納することで、フォントとして表示されるようにする。 SVG フォントといった場合、符号が与えられていない場合は問題ないのか。 それは問題ない。HTML にインラインで書くこともできるので、その場合は埋め込み フォントにもなる。 SVG フォントは、色を付けたり、アニメーションするなど一般的なメリットがあるが、 それが行政における符号化されていない人名文字の表記に対してどのようなメリット があるのかというと、他のフォントと比べて大して差はないのではないか。 そのあたりを実証実験で比較評価できるのではないか。 実証実験では、時間やコストの制約はあるものの、理想的には様々な方法のベンチマー クを取るようなサイトを用意し、いろいろな環境の評価を行いたい。 3. 実証実験要件案について 資料 2 の実証実験要件（案）について事務局沼田より説明。 【質疑応答】 WEB フォントの実証実験を行うのか否かが重要となると思うが。 IPAmj 明朝を一般のユーザがインストールしなければならいないと考えたときに、非 常にハードルが高い問題がある。 2000 年版や 2004 年版の違いもあるため、この分野においてはクリティカルな問題で ある。 実用上は、差分をダウンロードする方法の方がメジャーである。大体システムに入っ ている文字は、システムの文字を表示し、それ以外は IPAmj 明朝を使うのが良いので はないか。 しかし、その場合、同一のコードポイントの文字であっても、IPAmj 明朝で IVS となっ ている文字が、システムに入っている文字と図形が異なっている場合がある。 システムのフォントと IPAmj 明朝が混在すると、文字図形が混在し実証実験としては 厳しくなる。 実際に使っている文字のみをエンベッドさせる方法がある。PDF のように使用してい る文字のみエンベッドする方法である。 入力の IME はどう実現するのか？
入力は、AjaxIME の利用を考えている。また、JIS X 0213 の範囲はシステムの IME を用いる。
WEB ブラウザで行う場合、HTML、CSS を WEB フォントが、JIS X 0213 はローカ ルを使ってもらい、それ以外は動的な Web フォントを作り、IPAmj 明朝を利用しても らうということもできる。
JIS X 0213 範囲（包摂基準内）であっても、字形が異なっているので、この実証実験 では IPAmj 明朝の字形を使ってもらう必要がある。 実証実験では、IPAmj 明朝決め打ちで行うべきである。 では、IPAmj 明朝を使い、ユーザの端末にはインストールしないで実証実験を行うに はどのようにすべきかを考える。 WOFF で Web フォントにするとして、欧米ではもう利用されているが、日本では文字 数が多いためにあまり利用されていないが、常に文字集合すべてをダウンロードする のは困難である。例えば、文字コードの範囲毎に分割して、随時必要なところだけ WOFF をダウンロードして使用するという方法ならば実現できるのではないか。 WOFF と Web フォントはどのように異なるのか。 WOFF というのは、CSS の用語であり、フォントのフォーマットである。一方、Web フォントは、Web でフォントを扱う仕組み全体を示す。 サーバ側で表示に必要な最低限の文字集合を動的に格納したフォントを作り、サブ セットフォントとして送信し、クライアントは Web フォントとしてダウンロードする。 先ほどの文字コードの範囲に分割する方法は、例えば 45MByte の IPAmj 明朝を都合 のいい粒度に分割するということである。コードレンジ単位であっても、歯抜けがあっ てもよいので、様々なパターンで分割するとよい。どういう粒度、どのように分ける のかということを評価することは、日本語の Web フォントや WOFF が利用できるよ うために重要である。 一文字単位で、表示に必要な文字をオンザフライで格納できるフォントがあるのであ れば、その方法は不要なのではないか。 そうはならないと考えているが。 ある粒度でフォントを分割する方法は、ダウンロードに時間はかかるものの、ある程 度長い期間キャッシュされる場合に有効である。一方で、オンザフライでは常にリク エストが発生するとサーバサイドの負荷が増す問題がある。 コード領域で分割するのは、IPA フォントライセンスに抵触する。ほとんどのフォント もライセンス的にそのような使い方は、許可されていない。 今回の実証実験は、IPA からの配布となるので、再配布にはあたらず一次配布であるか ら、どのように変更してもライセンスの問題は生じない。しかし、ユーザがダウンロー ドした場合に、クライアント端末にファイルが残ったとしても、そのファイルが一次 配布となるため、そのファイルを起点として、改変等した場合に再配布となる。こう なると、無数の IPA フォントのバリエーションが生成されてしまう問題が生じる。 「キャッシュとして残さない。あるいは、再配布を想定しない。」ということも考えら れるが、IPA フォントライセンスが適用できなくなる。 オンザフライで、再配布を想定しないものだとするべきか。WOFF の場合は、そのよ うなことも考慮されているのか。 WOFF は、ブラウザからすると使い捨てとなっている。参照するときは、URL をたど るか、キャッシュファイルをたどるかの違いしかない。 6
まとめると、Dynamic 方式は、サーバサイドの負荷がかかることであり、分割方式は ライセンス上の問題があるのではないかということになる。 WOFF であれば、キャッシュになるのでライセンス問題は解決されるのではないか。 キャッシュファイルの参照は、Web にアクセスしているのと同一であるため、その違 いについて説明は難しい。 ダウンロードフォントを行う場合に、フォーマットは何を考えているのか。 今は、TTF のままが良いと考えているが、今後検討が必要である。 キャッシュさえているものをユーザが開いてみたり、コピーすることができるが、そ れは問題ないということでよいか。 明示的にサブセットフォントを配布するとライセンス上、IPA がサブセットフォントを 一次配布していることになるが、サーバモデルとして行うと考えれば場合は許諾対象 となる。 サーバサイドへの負荷等もあるので、両方式を試してみる必要がある。 やはり、WOFF を使って、実証実験をすることに意義があると考えている。最新の Web ブラウザがサポートして、欧米では実用が始まっているが、日本では使用されて いないことがある。
しかし、分割した WOFF 等を利用する場合は、CMAP が分割されるなど Feature Table で問題が生じる。今回の実証実験では、IVS を扱う必要がある。また、実験の対象を卒 業証書等にして、縦書きを利用することも考えられる。Feature Table を用意したうえ で、動的に生成すれば実証実験に幅を持たせることができる。 おそらく縦組みをハンドリングできるブラウザはないのではないか？Feature Flag を 見ているブラウザはあまりないのではないか。 今後、WOFF は世界的にみて表示のメカニズムの主流になると考えられる。WOFF を 日本語フォントで扱う場合に、分割が必要になった場合に生じる課題を実験で整理す るということも求められるのではないか。 MJ 文字図形名の ASCII 文字列、複数の文字コードを組み合わせ、一つの文字を表す という方法は許容されないのか？例えば、８文字分のシーケンスで一文字を表すと いった手法である。「ある文字列シーケンスを IPAmj 明朝フォントでみるとリガチャ テーブルを参照して漢字が表示されるが、別のフォントでみると文字列のまま MJXXXXXX が見える」というのはどうか？ リガチャの本質ではないと批判される可能があるが、リガチャテーブルをオンザフラ イで、&MJXXXXXX;を一文字で作る。 不可能ではない。実験することはできる。 しかし、Feature Table を参照しているブラウザは少ないため、リガチャテーブルを利 用する手法はおそらくブラウザ依存になる。 フォントファイルを参照しているわけではなく、リガチャとしているわけではないた め、OS 依存となっている。 リガチャテーブルを参照するレンダリングになると負荷が大きくなる問題もあり、利 7
用は難しい。 やはり、ブラウザに依存しない方法を考えると、Img タグに Alt 属性を書き、インライ ングラフィックで行う方法となるのではないか。 その場合、動的にフォントを作成するときの負荷などは、やはり評価が必要である。 実証実験でサーバサイドのプログラムに求められることは、IVS に対応できないブラウ ザについては、サーバが識別して表示できない旨を端末に通知することが一段階目、 ほかの代替方法により表示することが二段階目であり、文字化けしないようにするこ とが必須である。 実証実験では、IVS に対応していないブラウザを持つ端末がどの程度あるのか、統計を 取ることも必要。 キャラクターリファレンスで、符号化外文字は、&MJXXXXXX;であり、IVS は &U+XXXX; &U+0EXXXX;とするのがよい。 デモシナリオ この実証実験に期待される点が、全部の文字の表示が可能で、入力の方法も作成され ることであるならば、現在行われている電子申請の入力フォームとなるようなものが よい。例えば、住民票の写しの請求であったり、施設予約であってもよい。カードが 発行されていて、カード番号が入力すると、名前の表示や予約登録ができるといった ことができればよい。 実際に自分の文字が表示されなく困っている人は、人口の割合で言えば少ないと思わ れるが、実証実験では、普段見ることのないような変わった文字を簡単に入力・表示 できるようにして、文字が好きな人が楽しめるような側面も必要である。 一方で、文字情報基盤の成果物を一般に周知する側面。それが、現在の技術で利用で きるのかということを検証する側面。それを応用して、将来の政府・自治体・民間の 連携の側面。これらを実験シナリオの前提と考えなければならない。 運用検討 WG にもシナリオを考えてもらうべきだ。 運用検討 WG は、自治体の方も委員として参加しているので、自治体が今後使うもの のテーマとして、デモ実証実験後に自治体で抱えている電子申請や施設予約で抱えて いる問題の解決に役立つようなものも含めたい。 4. その他 たたき台をメールで、次回開催で具体的な仕様を検討・決定する。次回開催予定日、第 １候補 10 月 7 日（金）15:00～17:00、第２候補 10 月 6 日（木）10:00～12:00 を予定。 以上 8
