JP2008117319A - 情報処理装置、情報処理装置の制御方法およびプログラム - Google Patents

Abstract

【課題】ＧＵＩを構成するＧＵＩデータの容量を低減可能とする技術を提供する。
【解決手段】グリフデータサブセットを作成する情報処置装置において、グリフデータセットを記憶する記憶手段と、ＧＵＩで使用される文字コード列情報を入力する入力手段と、文字コード列に出現する文字コード群を収集する収集手段と、収集された個々の文字コードに対応するグリフデータを記憶手段から抽出する抽出手段と、抽出されたグリフデータからグリフデータサブセットを生成する生成手段とを備える。
【選択図】図７

Description

本発明は、グラフィカル・ユーザ・インタフェース（ＧＵＩ）の表示に使用されるデータのデータ生成技術に関するものである。特に多言語対応ＧＵＩにおけるデータ量削減に関する。

端末機器に搭載されるグラフィカル・ユーザ・インタフェース（以降、ＧＵＩと呼ぶ）は、アプリケーション開発者によってデザインされ、一般にＧＵＩ制御プログラム等と一体化している。そのため、ＧＵＩのデザインを変更する際には、デザインに関する部分だけでなくＧＵＩ制御プログラムについても変更を加え、プログラムを再生成（リビルド）する必要があった。

これを解決するためのアプリケーション開発手法として、ＧＵＩのデザインとプログラムを分離し、デザインの変更を容易にするモデルとしてＭＶＣ（Ｍｏｄｅｌ、Ｖｉｅｗ、Ｃｏｎｔｒｏｌｌｅｒ）モデルに従った開発方法がある。ＭＶＣモデルのＶｉｅｗに相当するのがＧＵＩのデザインであり、Ｍｏｄｅｌに相当するのがＧＵＩ制御プログラムである。ＭＶＣモデルによれば、ＧＵＩのＭｏｄｅｌであるプログラムとＶｉｅｗであるデザインとは疎な結合となっている。そのため、それぞれを独立して作業を進めることができる。つまり、デザインに影響を与えずにプログラムを変更することが可能であり、またプログラムに影響を与えずにデザインを修正することができるので、効率化を図ることができる。

ところで近年、グラフィカルユーザインタフェースを搭載した機器の多言語対応が求められている。例えば、特許文献１には、利用者属性情報に合致したＵＩを端末で自動的に選択する技術が開示されている。ここで、多言語対応とは、グラフィカルユーザインタフェースのデザインは変更せずに、使用されている言語のみを変更することを意味する。先に述べたＭＶＣモデルに従えば、プログラムは共通して使用することができ、デザインのみ変更することで、多言語への対応が可能である。

ただし、多言語対応はプログラムと対応する言語の両方を熟知しているものによってなされないと、ミスが発生する可能性が非常に高い。一般的には、プログラムに使用する文字を他の言語に置き換える翻訳作業は、その言語を熟知している人に依頼される。そして、プログラマーは翻訳されたデータをプログラムの中に書かれている言語と差し替える。しかしこの差替作業は煩雑であり、プログラマーがその言語について熟知していない場合はミスに気づかない可能性が非常に高い。このような問題を解決するために、文字データを外部ファイルとして参照し、動作言語モードを設定することによりＧＵＩの表示文字列の言語を動的に切り換えるということが行われている。

図１は上述の手法を説明する図である。端末機器１００は、対応する言語で書かれた文字列データ１１１〜１１３を記憶するＲＯＭ１１０を備えている。また、端末機器１００は、文字列データ選択部１３０からの要求に応じて端末機器の現在の言語モードを返す言語モード取得部１２０を備えている。そして、端末機器１００がコンポーネントに文字列をレンダリングする際に、グラフィカルユーザインタフェース合成部１４０は、文字列データ選択部１３０に文字列データの取得要求を出す。すると、文字列データ選択部１３０は言語モード取得部１２０から現在の言語モードを取得し、その言語モードに対応する文字列データを取得する。たとえば、英語が選択されていれば、文字列データＡ１１１からデータを取得する。つまり、図では、“ＹＥＳ”の文字列データを取得する。同様に日本語であれば文字列データＢ１１２から“はい”を、ドイツ語であれば文字列データ１１３から“Ｊａ”というデータを取得する。そして、取得した文字列にしたがってグラフィカルユーザインタフェース合成部１４０においてレンダリング処理がなされる。このように、複数の言語についての文字列データを外部ファイルとして用意し、それを動作言語モードによって切り換えることが可能となる。
特開２００３−３２３５６号公報

しかしながら、上述した文字データを外部ファイルとして参照する手法によれば、選択可能な言語で使用される文字に対応するグリフデータのセットを機器に記憶しておく必要がある。例えば、日本語、英語、ドイツ語の３言語で使用される文字に対応するグリフデータが必要となる。通常、それぞれの言語に対応するグリフデータは、各言語で用いられる全ての文字が含まれるため、データ量が膨大になる。パーソナルコンピュータ（ＰＣ）のように処理能力や記憶容量などのリソースが潤沢にある場合には問題にならないが、小型端末のようにリソースに制限がある場合には多言語のグリフデータを記憶することは困難となる。

ところで、文字を外部ファイルでなくコンポーネントデータの一部としてビットマップ化し記憶することにより、使用するグリフデータを低減する方法もある。しかしながら、この方法では、異なる言語表示を選択する場合には、同じ画面（図形）を表示する場合においてもコンポーネントデータを言語種別ごとに用意しなければならず、コンポーネントデータのデータ量が増大する。また、デザイン変更の際に、複数の言語に対応する全てのコンポーネントデータに対し変更が必要になり、フレキシブルな対応が困難になるという問題点がある。

本発明は上記問題点に鑑みなされたものであり、その主な目的は、ＧＵＩを構成するＧＵＩデータの容量を低減可能とする技術を提供することにある。

上述した問題点を解決するために、本発明の情報端末用のグリフデータサブセットを作成する情報処置装置は、前記情報端末で利用するためのグリフデータセットを記憶する記憶手段と、前記情報端末で使用されるＧＵＩの文字コード列情報を入力する入力手段と、入力した文字コード列に出現する文字コード群を収集する収集手段と、該収集手段で収集された個々の文字コードに対応するグリフデータを前記記憶手段から抽出する抽出手段と、抽出されたグリフデータをそれぞれが対応する文字コードと対応付けグリフデータサブセットを生成する生成手段とを備える。

ここで、前記生成手段は、抽出されたグリフデータを前記情報端末で処理可能なデータ形式に変換し前記グリフデータサブセットを生成する。

また、前記情報端末は、前記文字コード列の情報を有するＧＵＩコンポーネント群と前記グリフデータサブセットとに基づいて前記ＧＵＩに文字列画像を表示し、該ＧＵＩコンポーネントは該文字列画像の表示位置情報を含んでおり、前記生成手段は、前記表示位置情報に基づいて、前記グリフデータサブセットを生成する。

そして、前記グリフデータサブセットは、２以上の言語のグリフデータを含む。また、前記文字コード列は、Ｕｎｉｃｏｄｅのコードポイントにより表現される。

上述した問題点を解決するために、本発明の情報端末用のグリフデータサブセットを作成する情報処置装置の制御方法は、前記情報端末で使用されるＧＵＩの文字コード列情報を入力する入力工程と、入力した文字コード列に出現する文字コード群を収集する収集工程と、該収集工程で収集された個々の文字コードに対応するグリフデータを前記グリフデータを記憶する記憶部から抽出する抽出工程と、抽出されたグリフデータをそれぞれが対応する文字コードと対応付けグリフデータサブセットを生成する生成工程とを備える。

上述した問題点を解決するために、本発明の情報端末用のグリフデータサブセットを作成するプログラムは、前記情報端末で使用されるＧＵＩの文字コード列情報を入力する入力工程と、入力した文字コード列に出現する文字コード群を収集する収集工程と、該収集工程で収集された個々の文字コードに対応するグリフデータを前記グリフデータを記憶する記憶部から抽出する抽出工程と、抽出されたグリフデータをそれぞれが対応する文字コードと対応付けグリフデータサブセットを生成する生成工程と、をコンピュータに実行させることを特徴とする。

本発明によれば、ＧＵＩデータの生成におけるデータ量削減を可能とする技術を提供することができる。

以下に、図面を参照して、この発明の好適な実施の形態を詳しく説明する。ただし、この実施の形態に記載されている構成要素はあくまで例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。

（第１実施形態）
＜概要＞
ＧＵＩ表示が可能な機器として、携帯情報端末を例とする。複写機や撮像機で実施可能なことは言うまでもない。携帯情報端末においては、記憶部に記憶可能なデータ量に制約がある。一方、上述した、端末機器の動作から分かるように、文字列データテーブルに使用されていない文字（文字コード）に対応するグリフデータは参照されることがない。つまり、記憶されているグリフデータには余分なグリフデータが多い。そこで、第１実施形態のＧＵＩデータ生成装置では、ＧＵＩ表示に使用されるグリフデータを判定し、使用されるグリフデータのみを携帯情報端末の記憶部に記憶することにより、必要なＧＵＩデータ量の削減を実現する。

以下では、まずＧＵＩデータを利用しＧＵＩを表示する携帯情報端末の構成と動作について説明し、その後、当該ＧＵＩデータの生成方法について述べる。

＜携帯情報端末の構成＞
図２は、ＧＵＩを備える携帯情報端末の内部構成図である。携帯情報端末２００は、各種プログラムを実行するＣＰＵ２０１、各種プログラムおよび各種データを記憶するＲＯＭ２０２、各種データを一時記憶するＲＡＭ２０３を備えている。なお、ＲＡＭ２０３は、ＣＰＵ２０１が各種プログラムを実行する際のワークメモリとしても利用される。さらに、携帯情報端末２００は、キーボードやタッチパネルなどにより構成される操作入力部２０４、および、ＬＣＤなどにより構成され各種画面を表示する表示部２０５を備える。

図３は、携帯情報端末の機能ブロック図である。携帯情報端末２００は、システムイベント送信部３０１ａ、ユーザイベント送信部３０１ｂ、イベント受信部３０２を備えている。これらの各機能部は、ＣＰＵ２０１がＲＯＭ２０２に記憶された各種プログラムを実行することにより実現される。システムイベント送信部３０１ａは、一定時間ごとに発生するタイマーやシャットダウンなどを含んだシステムの発生するイベントを送信する機能部である。ユーザイベント送信部３０１ｂは、ユーザが操作することによって発生するイベントを送信する機能部である。イベント受信部３０２は、システムイベント送信部３０１ａ、ユーザイベント送信部３０１ｂからイベントが入力されるのを待機しており、信号が入力されるとＧＵＩ合成部３０３に通知する。

また、図３には、ＲＯＭ２０２に記憶されるＧＵＩ関連のデータを例示的に示している。なお、以降では以下の（ａ）〜（ｄ）のデータを総称して”ＧＵＩデータ”と呼ぶ。ＧＵＩ合成部３０３は、イベント受信部３０２から通知された信号に基づいてＲＯＭ２０２からＧＵＩデータを取得するよう構成されている。

（ａ）”レイアウトデータ”
レイアウトデータは、ＧＵＩ画面上での後述するコンポーネントデータの配置や、配置された各コンポーネントに関連付けられる文字列と対応付けを定義している。なお、コンポーネントおよび文字列の特定には後述するコンポーネントＩＤ、文字列ＩＤを用いる。このレイアウトデータは、レイアウトデータ保存部３１１に記憶されている。また、レイアウトデータは、表示部２０５に表示される様々な画面毎に用意される。より具体的には、レイアウトデータはコンポーネントのレイアウトと、それぞれ配置すべきコンポーネントを特定するコンポーネントデータＩＤと、そこに表示すべき文字列を特定する文字列データＩＤを記述したものである。なお、図においてコンポーネントデータの配置位置を点線枠で示している。

（ｂ）”コンポーネントデータ”
コンポーネントデータは、ＧＵＩ画面上に配置されるボタンなどの形状や色などのデザインを表現するデータである。それぞれのコンポーネントデータにがコンポーネントＩＤが割り振られる。このコンポーネントデータは、コンポーネントデータ保存部３１２に記憶されている。また、コンポーネントデータは１以上のレイアウトデータにより参照される。なお、それぞれのコンポーネントにはＩＤ（コンポーネントＩＤ）が振られている。また、ＧＵＩ上でコンポーネント上に文字列が表示される際のバウンディングボックスなどのレイアウト情報も合わせて定義されている。なお、図においてバウンディングボックスのイメージを点線枠で示している。

（ｃ）”文字列データ”
文字列データは、ＧＵＩ画面上に表示される文字列をＵｎｉｃｏｄｅのコードポイント（文字コードとも呼ばれる）で表現したものである。そして、文字列データはそれぞれを特定するための文字列データＩＤと対応付けて文字列データテーブルとして文字列データテーブル保存部３１３に記憶されている。例えば、英語であれば文字列データとして“Ｙｅｓ”の文字列を示す文字コード列である”Ｕ＋００５９，Ｕ＋００６５，Ｕ＋００７３”を取得する。また、同様に日本語であれば文字列データとして“はい”の文字列を示す文字コード列である”Ｕ＋３０６Ｆ，Ｕ＋３０４４”を取得する。さらに、ドイツ語であれば文字列データとして“Ｊａ”の文字列を示す文字コード列である”Ｕ＋００４Ａ，Ｕ＋００６１”というデータを取得する。文字列データには、各言語に対応した文字列が記憶されている。なお、文字コードとしては、多言語を統一的に取り扱うことが可能なＵｎｉｃｏｄｅを利用することが好適である。

（ｄ）”グリフデータ”
それぞれのコードポイントに対応させた文字形状（グリフ）を定義したデータである。このグリフデータは、グリフデータ保存部３１４に記憶されている。なお、文字形状をビットマップ画像として定義するようにしても良いし、ベクトルデータとして定義しても良い。ただし、ベクトルデータの場合は、データ容量を抑制するために、詳細な形状までは記憶せず基本的な文字形状のみを記憶することが好適である。つまり、ＧＵＩ表示の画面解像度に必要な程度の形状が得られれば足りる。

なお、グリフとは、一般的に、文字の可視化表現又はその構成部分から大きさ及び意匠を正規化した抽象表現(JIS X 4161及びISO/IEC 10036を参照)を指し、フォントに含まれる描画内容の最小単位のことである。描かれる文字は一般的にはグリフと１対１に対応する（例えば文字 "A" はたいていは一つのグリフで描画される）。しかし、単一の文字に複数のグリフが使用されることもあるし（例えばアクセント付き文字）、複数の文字に単一のグリフが使用されることもある（例えばリガチャ）。そして、一般的にグリフはいくつかの パス などの 図形 により定義され、場合によっては付加的情報（フォントエンジンがテキストを小さいサイズでも読み取りやすく描画できるようにするためのヒント情報など）を持つことがある。

＜携帯情報端末のＧＵＩ表示動作フロ−＞
図４は、携帯情報端末がＧＵＩ画面を更新する際の処理フローを示した図である。なお、以下の処理はＣＰＵ２０１がＲＯＭ２０２に記憶されたＧＵＩ表示プログラムを実行することにより実現される。また、ここでは、携帯情報端末２００の電源がＯＮされており、すでにＧＵＩの初期画面が表示されている状態であるとする。そして、イベント受信部３０２によるイベント受信をトリガに以下のフローが実行される。

ステップＳ４０１では、ＣＰＵ２０１は、イベント受信部３０２が受信したイベントが、ＧＵＩ表示の更新を必要とするイベントかどうかを判断する。例えば、イベント受信部３０２に入力されたシステムイベント送信部３０１ａまたはユーザイベント送信部３０１ｂからのイベントが、言語変更指示のようにＧＵＩ表示を更新する必要のあるイベントか否かを判断する。ＧＵＩ表示の更新を必要とするイベントであればステップＳ４０２に進み、それ以外のイベントであればステップ４０１に戻る。システムイベントとしては、携帯情報端末２００で動作するアプリケーションプログラムやシステムプログラムによる画面更新指示などがあり、ユーザイベントとしてはユーザの操作入力部２０４の操作による直接的な画面更新指示がある。

ステップＳ４０２では、受信したイベントに基づいて、レイアウトデータ保存部３１１に記憶されているレイアウトデータを読み取る。

ステップＳ４０３では、ステップＳ４０２で読み取ったレイアウトデータに記述されるコンポーネントＩＤを取得する。そして、取得したコンポーネントＩＤそれぞれに対応するコンポーネントデータをコンポーネントデータ保存部３１２から読み取る。例えば、ステップ４０２で読み取ったレイアウトデータが図４に示されるようなデータの場合、コンポーネントＩＤがＣ−１、Ｃ−２およびＣ−３の３つのコンポーネントが読み取られる。

ステップＳ４０４では、ステップＳ４０２で読み取ったレイアウトデータに記述される文字列データＩＤを取得する。そして、取得した文字列データＩＤそれぞれに対応する文字列データを文字列データテーブル保存部３１３から読み取る。例えば、ステップ４０２で読み取ったレイアウトデータが図４に示されるようなデータの場合、文字列データＩＤがＳ−１およびＳ−２の２つの文字列データが読み取られる。

ステップＳ４０５では、ステップＳ４０４で読み取った文字列データに含まれるコードポイント（文字コード）に対応するグリフデータをグリフデータ保存部３１４から読み取る。例えば、ステップＳ４０４において読み取った文字列データが”Ｕ＋３０６４、Ｕ＋３０４Ｅ”であれば、グリフデータ保存部３１４から”つ”および”ぎ”の文字に対応するグリフデータを取得する。

ステップＳ４０６では、ＧＵＩ合成部３０３は、ステップＳ４０２〜ステップＳ４０５で読み取ったＧＵＩデータに基づいてＧＵＩ表示画面を構成し表示部２０５に表示する。

以上のステップを実行することによりＧＵＩ表示の更新がなされる。。例えば、ユーザの操作により表示する言語モードが切り換えられると、制御プログラムにより文字列データが参照される。そして、文字コードに対応する文字形状がグリフデータから読み込まれＧＵＩ上に表示される。このようにして、多言語表示の動的な切り換えが実現される。

また、以上の動作ステップから、例えば、携帯情報端末２００が表示可能な言語を追加する処理は簡単なものであることが理解される。つまり、当該追加言語の（ｃ）”文字列データ”（ｄ）”グリフデータ”を新たにＲＯＭ２０２に記憶し、（ａ）”レイアウトデータ”の修正を行えばよいことが理解される。一般的にデータの消費容量は（ｄ）”グリフデータ”が大部分を占めるため、以下では主にグリフデータのデータ量低減技術について述べる。

＜ＧＵＩデータ生成装置の構成＞
図５は、第１実施形態に係るＧＵＩデータを生成する情報処理装置の内部構成図である。

情報処理装置５００は、各種プログラムを実行するＣＰＵ５０１、各種プログラムおよび各種データを記憶するＲＯＭ５０２、各種データを一時記憶するＲＡＭ５０３を備えている。なお、ＲＡＭ５０３は、ＣＰＵ５０１が各種プログラムを実行する際のワークメモリとしても利用される。また、大容量の記憶装置であるＨＤＤ５０６を備え、後述するＧＵＩデータ生成プログラムを含む各種プログラムおよびＧＵＩデータを記憶する。さらに、情報処理装置５００は、キーボードやマウスなどにより構成される操作入力部５０４、および、ＬＣＤなどにより構成され各種画面を表示する表示部５０５を備える。なお、情報処理装置５００は、一般的なパーソナルコンピュータ（ＰＣ）において後述するＧＵＩデータ生成プログラムを実行することにより構成することが出来る。

図６は、第１実施形態に係るＧＵＩデータを生成する情報処理装置の機能ブロック図である。情報処理装置５００は、コンポーネントデータ取得部６０１、文字列レイアウト情報取得部６０２、文字列データ取得部６０３、グリフデータ選択部６０４、および、グリフデータ生成部６０５を備える。これらの各機能部は、ＣＰＵ２０１がＲＯＭ２０２に記憶された各種プログラムを実行することにより実現される。また、記憶手段であるＨＤＤ５０６には、レイアウトデータ保存部６１１、コンポーネントデータ保存部６１２、文字列データテーブル保存部６１３、および、グリフデータ保存部６１４が構成されている。そしてこれらの保存部それぞれには図３を用い説明した以下の４つのデータ（ＧＵＩデータ）が記憶されている。

（ａ）”レイアウトデータ”
（ｂ）”コンポーネントデータ”
（ｃ）”文字列データ”
（ｄ）”グリフデータ”

ただし、情報処理装置５００のＨＤＤ５０６内に記憶される（ｂ）〜（ｄ）の各データは、上述の携帯情報端末２００のＲＯＭ２０２に記憶されるデータのスーパーセットとなっている。すなわち、より多種多様なデータが記憶されている。例えば、コンポーネントデータとしてより多種の図形が記憶され、グリフデータとしては様々な文字各種言語で使用されうる全ての文字のグリフデータが記憶されている。

コンポーネントデータ取得部６０１は、レイアウトデータ保存部６１１から取得したレイアウトデータに基づいてコンポーネントデータ保存部６１２からコンポーネントデータを取得する機能部である。つまり、レイアウトデータに記述されるコンポーネントＩＤに対応するコンポーネントデータを取得する。

文字列レイアウト情報取得部６０２は、コンポーネントデータ取得部６０１で取得したコンポーネントデータに記述されるレイアウト情報（バウンディングボックスなど）を取得する機能部である。

文字列データ取得部６０３は、レイアウトデータ保存部６１１から取得したレイアウトデータに基づいて文字列データテーブル保存部６１３から文字列データを取得する機能部である。つまり、レイアウトデータに記述される文字列データＩＤを入力する入力手段と、対応する文字列データを収集する収集手段とに相当する機能部である。

グリフデータ選択部６０４は、文字列データ取得部６０３で取得した文字列データに含まれる文字コードに対応するグリフデータをグリフデータ保存部６１４から抽出する抽出手段に相当する機能部である。

グリフデータ生成部６０５は、グリフデータ選択部６０４で選択したグリフデータをグリフデータ保存部６１４から読み込む。そして、文字列レイアウト情報取得部６０２で取得したレイアウト情報に基づいて、当該グリフデータを拡大、縮小、あるいはデータフォーマット変換を行ない、携帯情報端末２００で利用可能なグリフデータを生成する。つまり、生成手段に相当する。

＜ＧＵＩデータ生成装置の動作フロー＞
図７は、第１実施形態に係る情報処理装置のＧＵＩデータ生成のフローチャートである。以下の処理は、例えば、ＧＵＩ設計が終了し、（ａ）”レイアウトデータ”および（ｂ）”コンポーネントデータ”が作成された状態から開始される。また、レイアウトデータに記述される文字列データＩＤの（ｃ）”文字列データ”も併せて作成されているものとする。

ステップＳ７０１では、コンポーネントデータ取得部６０１は、レイアウトデータ保存部６１１から未処理のレイアウトデータを読み取り、レイアウトデータに記述されるコンポーネントＩＤのリストを生成する。

ステップＳ７０２では、コンポーネントデータ取得部６０１は、ステップＳ７０１で生成されたリストに含まれるコンポーネントＩＤと一致するコンポーネントデータをコンポーネントデータ保存部６１２から取得する
ステップＳ７０３では、文字列レイアウト情報取得部６０２は、ステップＳ７０２で取得したコンポーネントデータに含まれる文字列レイアウト情報を取得する。

ステップＳ７０４では、文字列データ取得部６０３は、ステップＳ７０１で取得したレイアウトデータに基づいて、文字列データテーブル保存部６１３から当該文字列データを取得する。

ステップＳ７０５では、グリフデータ選択部６０４は、ステップＳ７０４で取得した文字列データに含まれる文字コードを抽出する。なお、多言語対応の場合など、複数の文字セット（アルファベット、漢字などの文字集合）が存在する場合には、統一的な文字コード体系であるＵｎｉｃｏｄｅのコードポイントなどに変換するのが好適である。

ステップＳ７０６では、グリフデータ生成部６０５は、ステップＳ７０５で選択されたコードポイントに対応するグリフデータが、既に生成されたグリフデータであるか否かを判定する。つまり、現在のグリフデータサブセットに当該コードポイントに対応するグリフデータが存在するか否かを判定する。存在する場合は、ステップＳ７０８に進み、存在しない場合はステップＳ７０７に進む。

ステップＳ７０７では、グリフデータ生成部６０５は、まだグリフデータサブセットに存在しないと判定されたコードポイントのグリフデータを、グリフデータ保存部６１４から抽出する。そして、ステップＳ７０３で取得したレイアウト情報に基づいて、当該グリフデータを拡大、縮小、あるいはデータフォーマット変換を行いグリフデータを生成する。生成したグリフデータはグリフデータサブセット内に格納される。

ステップＳ７０８では、コンポーネントデータ取得部６０１は、全てのレイアウトデータについて上述の処理を終了したか否かを判定する。未処理のレイアウトデータがあればステップＳ７０１に進み、全て終了していればフローを終了する。

次に上述のステップＳ７０７における処理をさらに詳細に説明する。

図８は、ステップＳ７０７の処理の詳細フローチャートである。ここでは、グリフデータ保存部６１４に記憶されたグリフデータを携帯情報端末２００で処理可能な形式に変換し生成する処理について述べる。つまり、ＨＤＤ５０６のグリフデータ保存部６１４に記憶されているグリフデータが、携帯情報端末２００に適していないデータ形式である場合の処理について述べる。例えば、グリフデータが携帯情報端末２００で処理不可能な形式である場合や、不必要に詳細なデータである場合などが相当する。後者の例としては、ＰＣのオペレーティングシステム（ＯＳ）でも利用されているＴｒｕｅＴｙｐｅ（登録商標）フォント形式があり、高解像度表示にも利用可能な高品質なベクトル形式のグリフデータである。

なお以下では、携帯情報端末２００で処理可能なグリフデータのフォーマットとして、ＳＶＧ（Ｓｃａｒａｂｌｅ Ｖｅｃｔｏｒ Ｇｒａｐｈｉｃｓ）において規定されるグリフデータ（ＳＶＧ Ｆｏｎｔ）を想定する。

ステップＳ８０１では、グリフデータ生成部６０５は、まだグリフデータサブセットに存在しないと判定されたコードポイントのグリフデータを、グリフデータ保存部６１４から抽出する。

ステップＳ８０２では、ステップＳ８０１で抽出されたグリフデータがＳＶＧ形式か否かを判定する。ＳＶＧ形式の場合は、ステップＳ８０４に進み、そうでない場合はステップＳ８０３に進む。

ステップＳ８０３では、ステップＳ８０１で抽出されたグリフデータから文字形状を抽出し、当該文字形状に基づいてＳＶＧ形式のグリフデータに変換する。

ステップＳ８０４では、ステップＳ７０３で取得したレイアウト情報に基づいて、ステップＳ８０３で変換したグリフデータから拡大、縮小を行いデータ量の削減を行う。データの削減方法としては、曲線の直線近似、また、近似精度の低減などを用いることが出来る。これは、例えばＴｒｕｅＴｙｐｅフォント形式などのデータからＳＶＧ形式に変換した場合、携帯情報端末２００では不必要な程度の高精度なＳＶＧ形式のデータとなるためである。

以上説明したとおり第１実施形態によれば、グリフデータ保存部３１４に必要とされる記憶容量を大幅に低減可能となることが理解できる。つまり、ＨＤＤ５０６に格納されたグリフデータサブセットを、携帯情報端末２００のＲＯＭ２０２内のグリフデータ保存部３１４に書き込む（図９）ことに大幅に低減可能となることが理解できる。また、不必要に高精度なデータでないため、グリフデータのレンダリング処理はより少ない処理量で済むことも理解できる。

特に、日本語など数千を超える数の文字が存在する文字種の多い言語のグリフデータは膨大なデータ量になる。例えば追加する言語が用いる文字数Ｕｎｉｃｏｄｅのコードポイントの数などに略比例し膨大なデータ量となる。また、多くの文字を処理するための処理能力も必要となるため携帯情報端末２００へのハードウェア要求を大幅に低減可能となる。また、ＧＵＩ表示の高速化も期待できる。

なお、上述の説明においては言語によらず同一の処理を行ったが、一部の言語のグリフデータのみ対象としても良い。例えば、文字の種類が少ない言語（英語など）に対応するグリフデータについては上述した処理を行わず、文字種の多い言語（日本語など）のグリフデータの場合のみ上述した処理を行うよう構成しても良い。

また、対応言語を追加する場合は、基本的に文字列データを変更するだけで良いため煩雑な作業によるミスを低減することができる。なお、デザイナーの要望などでレイアウトデータ・コンポーネントデータを変更する場合には、当該データを更新後、上述の処理を再度実行すればよく煩雑な作業によるミスを低減することができる。

（変形例）
ＧＵＩ用データを生成するためのオーサリングアプリケーションにおいては、あらかじめ汎用性のある標準的なコンポーネントセットが用意されている場合がある。例えば、三角形や四角形、円などの基本図形コンポーネント、各種デザインの矢印の矢印コンポーネント等から構成されるコンポーネントセットがある。

しかしながら、携帯情報端末２００では、これらのコンポーネントセットの全てを利用するとは限らない。そこで、本変形例では、実際に携帯情報端末２００で使用されるコンポーネントデータからなるコンポーネントデータサブセットの生成方法について説明する。なお、前提とする携帯情報端末２００および情報処理装置５００の構成は第１実施形態と同様であるため、説明は省略する。

＜ＧＵＩデータ生成装置の動作フロー＞
図１０は、変形例に係る情報処理装置のＧＵＩデータ生成のフローチャートである。以下の処理は、例えば、ＧＵＩ設計が終了し、（ａ）”レイアウトデータ”および（ｂ）”コンポーネントデータ”が作成された状態から開始される。また、レイアウトデータに記述される文字列データＩＤの（ｃ）”文字列データ”も併せて作成されているものとする。

ステップＳ１００１では、コンポーネントデータ取得部６０１は、レイアウトデータ保存部６１１から未処理のレイアウトデータを読み取り、レイアウトデータに記述されるコンポーネントＩＤのリストを生成する。

ステップＳ１００２では、コンポーネントデータ取得部６０１は、ステップＳ１００１で生成されたリストに含まれるコンポーネントＩＤと一致するコンポーネントデータをコンポーネントデータ保存部６１２から取得する。

ステップＳ１００３では、コンポーネントデータ取得部６０１は、ステップＳ１００２で取得されたコンポーネントデータが、既にコンポーネントデータサブセットに存在するか否かを判定する。存在する場合は、ステップＳ１００５に進み、存在しない場合はステップＳ１００４に進む。

ステップＳ１００４では、コンポーネントデータ取得部６０１は、ステップＳ１００２で取得されたコンポーネントデータをコンポーネントデータサブセットに追加する。なお、この時、携帯情報端末２００の表示部２０５の解像度に基づいて、データ形式・解像度の変換を行っても良い。

ステップＳ１００５では、コンポーネントデータ取得部６０１は、全てのレイアウトデータについて上述の処理を終了したか否かを判定する。未処理のレイアウトデータがあればステップＳ１００１に進み、全て終了していればフローを終了する。

以上説明したとおり変形例によれば、コンポーネントデータ保存部３１２に必要とされる記憶容量を低減可能となることが理解できる。つまり、ＨＤＤ５０６に格納されたコンポーネントデータサブセットを、携帯情報端末２００のＲＯＭ２０２内のコンポーネントデータ保存部３１２に書き込む（図９）ことにより低減可能となることが理解できる。また、不必要に高精度なデータでないため、ＧＵＩのレンダリング処理はより少ない処理量で済むことも理解できる。

（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

なお、本発明は、前述した実施形態の機能を実現するプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置が、供給されたプログラムコードを読み出して実行することによっても達成される。従って、本発明の機能処理をコンピュータで実現するために、コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク、磁気テープ、不揮発性のメモリカード、ＲＯＭなどがある。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。そして、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。

ＧＵＩの言語切替を説明する図である（背景技術）。 ＧＵＩを備える携帯情報端末の内部構成図である。 携帯情報端末の機能ブロック図である。 携帯情報端末がＧＵＩ画面を更新する際の処理フローを示した図である。 第１実施形態に係るＧＵＩデータを生成する情報処理装置の内部構成図である。 第１実施形態に係るＧＵＩデータを生成する情報処理装置の機能ブロック図である。 第１実施形態に係る情報処理装置のＧＵＩデータ生成のフローチャートである。 ステップＳ７０７の処理の詳細フローチャートである。 生成したグリフデータをＧＵＩデータとしてＲＯＭに書き込む様子を例示的に示す図である。 変形例に係る情報処理装置のＧＵＩデータ生成のフローチャートである。

Claims (7)

1. 情報端末用のグリフデータサブセットを作成する情報処置装置であって、
   前記情報端末で利用するためのグリフデータセットを記憶する記憶手段と、
   前記情報端末で使用されるＧＵＩの文字コード列情報を入力する入力手段と、
   入力した文字コード列に出現する文字コード群を収集する収集手段と、
   該収集手段で収集された個々の文字コードに対応するグリフデータを前記記憶手段から抽出する抽出手段と、
   抽出されたグリフデータをそれぞれが対応する文字コードと対応付けグリフデータサブセットを生成する生成手段と、
   を備えることを特徴とする情報処理装置。
2. 前記生成手段は、抽出されたグリフデータを前記情報端末で処理可能なデータ形式に変換し前記グリフデータサブセットを生成することを特徴とする請求項１に記載の情報処理装置。
3. 前記情報端末は、前記文字コード列の情報を有するＧＵＩコンポーネント群と前記グリフデータサブセットとに基づいて前記ＧＵＩに文字列画像を表示し、該ＧＵＩコンポーネントは該文字列画像の表示位置情報を含んでおり、
   前記生成手段は、前記表示位置情報に基づいて、前記グリフデータサブセットを生成することを特徴とする請求項２に記載の情報処理装置。
4. 前記グリフデータサブセットは、２以上の言語のグリフデータを含むことを特徴とする請求項１乃至請求項３の何れか一項に記載の情報処理装置。
5. 前記文字コード列は、Ｕｎｉｃｏｄｅのコードポイントにより表現されることを特徴とする請求項１乃至請求項４の何れか一項に記載の情報処理装置。
6. 情報端末用のグリフデータサブセットを該情報端末で利用するためのグリフデータセットから作成する情報処置装置の制御方法であって、
   前記情報端末で使用されるＧＵＩの文字コード列情報を入力する入力工程と、
   入力した文字コード列に出現する文字コード群を収集する収集工程と、
   該収集工程で収集された個々の文字コードに対応するグリフデータを前記グリフデータを記憶する記憶部から抽出する抽出工程と、
   抽出されたグリフデータをそれぞれが対応する文字コードと対応付けグリフデータサブセットを生成する生成工程と、
   を備えることを特徴とする制御方法。
7. コンピュータが読み込み実行することで、情報端末用のグリフデータサブセットを該情報端末で利用するためのグリフデータセットから作成する装置として機能させるプログラムであって、
   前記情報端末で使用されるＧＵＩの文字コード列情報を入力する入力工程と、
   入力した文字コード列に出現する文字コード群を収集する収集工程と、
   該収集工程で収集された個々の文字コードに対応するグリフデータを前記グリフデータを記憶する記憶部から抽出する抽出工程と、
   抽出されたグリフデータをそれぞれが対応する文字コードと対応付けグリフデータサブセットを生成する生成工程と、
   をコンピュータに実行させるためのプログラム。

Images