平成１４年度 情報技術開発支援事業審議委員会

Transcription

1 第 2 回文字情報基盤技術検討 WG 議事録 1. 日時平成 23 年 9 月 2 日 ( 金 )15:00~17:00 2. 場所 IPA 13 階会議室 C 3. 出席者 委員長 藤沢淳 キヤノン株式会社ソフトウェア応用第二開発部部長 W3C SVG WG メンバー EXI WG メンバー 委員 加藤誠 河合孝志 一般財団法人 Mozilla Japan テクニカルアドバイザ 株式会社日立製作所公共システム事業部全国公共ソリューション本部 自治体アプリケーション第二部課長 事務局 田代秀一小林龍生沼田秀穂池田佳代 4. 配布資料 < 配布資料 > 独立行政法人情報処理推進機構国際標準推進センター長独立行政法人情報処理推進機構国際標準推進センター専門委員独立行政法人情報処理推進機構国際標準推進センター研究員独立行政法人情報処理推進機構国際標準推進センター研究員 資料 1: 委員名簿資料 2: 第 1 回文字情報基盤技術検討 WG 議事録 5. 議事内容 1. 開会田代センター長より開会の挨拶 2. 前回議事録確認対象端末について 実証実験の対象端末の範囲はどのように考えているのか? 総務省の予算項目には 次世代ブラウザの開発というのが入るとのことである 総務省は 通信 放送を所管するため この次世代ブラウザの対象は PC だけではなくテレビや携帯電話等も含まれている このような端末のブラウザから電子行政へのアクセス等も考えられるので 検討する必要がある では 今回の実証実験は そのようなテレビやスマートフォントのブラウザも対象として考えているの? 現時点では 対象端末について白紙である しかし スマートフォンは考慮すべきで ある 1

2 PC は 技術的に先行しているが スマートフォンは PC に比べると遅れがある 現状のスマートフォントを対象に加えてしまうと 実証実験後の1 年 2 年経つと状況がかなり変わっていることが想定される スマートフォンが先行している PC に追いつてくることも考えられる 今のスマートフォン端末は PC と比較すると明らかな制限があることが分かっているので この状況を踏まえて実証実験を行うのは難しいのではないか スマートフォントの Web が PC のブラウザに追いつくまでに Android 2.3 だと1 年半くらい Apple 社であれば大体 1 年くらいのタイムラグがある では まとめると 数年後にはスマートフォンが 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

3 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

4 ないと文字列がそのまま表示されるものだが この手法を利用してユーザが MJ 文字図形名を目にするというのも良いのではないか キャラクターリファレンスは はじめから定義されているのか キャラクターリファレンスは あらかじめ定義されている 仕組みとしては パーサーが リプレースしているだけである 一般的なものではあれば キャラクターリファレンスは HTML の dtd で定義されている 実情としては dtd を読み込んで解釈しているのではなく 規格として定義されているので ブラウザ側であらかじめ用意している 一般的には ブラウザは把握できないが アドインのようにすることで解釈することができるということは可能か それは正規化のルールを用意すれば実現可能であると思われる キャラクターリファレンスの場合 ユーザ側はやはり置換される文字のフォントも持っているのか 例えば á の場合は á がレンダリングされる キャラクターリファレンスの場合 その文字列から Unicode に変換して コードポイントの文字を表示している では IVS も含めてキャラクターリファレンスは利用できるが 符号化外文字については扱うことができないということか カットバッファーに格納されるものについて 動きはないのか? セキュリティの話がからむと 難しい問題となる コピーで格納されるときに問題となる クリップボードを勝手に参照して 情報を送りつける等の操作が可能となってしまう インライン図形について 前回の議事録を確認すると インライン図形は SVG のファイルを HTML の Img タグで表示するというイメージか? それは 議題の焦点の一つであったが 委員長不在だったため議論が進んでいない 今回でスケーラブルな表示がしたいというのは要件であるのか? ビットマップを複数のサイズを用意して切り替えて使うという方法もあるので かならずしもアウトラインでなければならいというわけではない 逆に どのファイルフォーマットが適切なのかということを実験してみたいと考えている SVG フォントもメリットがある SVG であってもグラフィックの場合は あくまでグラフィックであるため 文字列として選択するとか アンダーラインを引くといった装飾など 文字としての振舞いができなくなる SVG フォントの場合は フォントと画像との間として よい落としどころになるので それも含めて検討したい SVG フォントについては ブラウザの対応が厳しいのではないか ただ新しい動きがでてきている OpenType に SVG フォントを入れるという議論がなされている OpenType にしても Web フォントの WOFF にしても その中身というのは TrueType のフォントである つまり フォントのフォーマットは同じで 4

5 あり コンテナが異なるだけである 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 明朝を利用してもらうということもできる 5

6 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

7 まとめると Dynamic 方式は サーバサイドの負荷がかかることであり 分割方式はライセンス上の問題があるのではないかということになる WOFF であれば キャッシュになるのでライセンス問題は解決されるのではないか キャッシュファイルの参照は Web にアクセスしているのと同一であるため その違いについて説明は難しい ダウンロードフォントを行う場合に フォーマットは何を考えているのか 今は TTF のままが良いと考えているが 今後検討が必要である キャッシュさえているものをユーザが開いてみたり コピーすることができるが それは問題ないということでよいか 明示的にサブセットフォントを配布するとライセンス上 IPA がサブセットフォントを一次配布していることになるが サーバモデルとして行うと考えれば場合は許諾対象となる サーバサイドへの負荷等もあるので 両方式を試してみる必要がある やはり WOFF を使って 実証実験をすることに意義があると考えている 最新の Web ブラウザがサポートして 欧米では実用が始まっているが 日本では使用されていないことがある しかし 分割した WOFF 等を利用する場合は CMAP が分割されるなど Feature Table で問題が生じる 今回の実証実験では IVS を扱う必要がある また 実験の対象を卒業証書等にして 縦書きを利用することも考えられる Feature Table を用意したうえで 動的に生成すれば実証実験に幅を持たせることができる おそらく縦組みをハンドリングできるブラウザはないのではないか?Feature Flag を見ているブラウザはあまりないのではないか 今後 WOFF は世界的にみて表示のメカニズムの主流になると考えられる WOFF を日本語フォントで扱う場合に 分割が必要になった場合に生じる課題を実験で整理するということも求められるのではないか MJ 文字図形名の ASCII 文字列 複数の文字コードを組み合わせ 一つの文字を表すという方法は許容されないのか? 例えば 8 文字分のシーケンスで一文字を表すといった手法である ある文字列シーケンスを IPAmj 明朝フォントでみるとリガチャテーブルを参照して漢字が表示されるが 別のフォントでみると文字列のまま MJXXXXXX が見える というのはどうか? リガチャの本質ではないと批判される可能があるが リガチャテーブルをオンザフライで &MJXXXXXX; を一文字で作る 不可能ではない 実験することはできる しかし Feature Table を参照しているブラウザは少ないため リガチャテーブルを利用する手法はおそらくブラウザ依存になる フォントファイルを参照しているわけではなく リガチャとしているわけではないため OS 依存となっている リガチャテーブルを参照するレンダリングになると負荷が大きくなる問題もあり 利 7

8 用は難しい やはり ブラウザに依存しない方法を考えると Img タグに Alt 属性を書き インライングラフィックで行う方法となるのではないか その場合 動的にフォントを作成するときの負荷などは やはり評価が必要である 実証実験でサーバサイドのプログラムに求められることは IVS に対応できないブラウザについては サーバが識別して表示できない旨を端末に通知することが一段階目 ほかの代替方法により表示することが二段階目であり 文字化けしないようにすることが必須である 実証実験では IVS に対応していないブラウザを持つ端末がどの程度あるのか 統計を取ることも必要 キャラクターリファレンスで 符号化外文字は &MJXXXXXX; であり IVS は &U+XXXX; &U+0EXXXX; とするのがよい デモシナリオ この実証実験に期待される点が 全部の文字の表示が可能で 入力の方法も作成されることであるならば 現在行われている電子申請の入力フォームとなるようなものがよい 例えば 住民票の写しの請求であったり 施設予約であってもよい カードが発行されていて カード番号が入力すると 名前の表示や予約登録ができるといったことができればよい 実際に自分の文字が表示されなく困っている人は 人口の割合で言えば少ないと思われるが 実証実験では 普段見ることのないような変わった文字を簡単に入力 表示できるようにして 文字が好きな人が楽しめるような側面も必要である 一方で 文字情報基盤の成果物を一般に周知する側面 それが 現在の技術で利用できるのかということを検証する側面 それを応用して 将来の政府 自治体 民間の連携の側面 これらを実験シナリオの前提と考えなければならない 運用検討 WG にもシナリオを考えてもらうべきだ 運用検討 WG は 自治体の方も委員として参加しているので 自治体が今後使うもののテーマとして デモ実証実験後に自治体で抱えている電子申請や施設予約で抱えている問題の解決に役立つようなものも含めたい 4. その他たたき台をメールで 次回開催で具体的な仕様を検討 決定する 次回開催予定日 第 1 候補 10 月 7 日 ( 金 )15:00 17:00 第 2 候補 10 月 6 日 ( 木 )10:00 12:00 を予定 以上 8