情報処理装置、データ処理方法、プログラム及び記憶媒体
【課題】 複数の文字コードが１つのグリフ（文字形状）を共通に使用している文字でも，中間フォーマットファイル内にアプリケーションが元々保持していた文字コードを格納することである。
【解決手段】 アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する際に、印刷命令のうち文字描画命令にグリフインデックスを含む場合、グリフインデックスに対応する文字コードを取得する（Ｓ９０８，Ｓ９０９）。そして、１つのグリフインデックスに対して割り当てられている複数の文字コードを使用していないグリフインデックスに割り当てる（Ｓ９１３，Ｓ９１４）。さらに、使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する（Ｓ９１５）ことを特徴とする。
【解決手段】 アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する際に、印刷命令のうち文字描画命令にグリフインデックスを含む場合、グリフインデックスに対応する文字コードを取得する（Ｓ９０８，Ｓ９０９）。そして、１つのグリフインデックスに対して割り当てられている複数の文字コードを使用していないグリフインデックスに割り当てる（Ｓ９１３，Ｓ９１４）。さらに、使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する（Ｓ９１５）ことを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置のデータ処理に関するものである。
【背景技術】
【０００２】
図１３は、従来の印刷システムに係る情報処理装置のモジュール構成を説明するブロック図である。本例は、ホストコンピュータ１０００とプリンタ１００４とが直接あるいはネットワーク経由で接続されている印刷システムに対応する。
【０００３】
図１３において、印刷処理は、ホストコンピュータ１０００のユーザが、ワードプロセッサプログラムや表計算プログラム等のアプリケーション１００１から、印刷指示を行うことによって開始する。
【０００４】
アプリケーション１００１は、文字描画データ等を含むアプリケーションデータを解析して、例えばＯＳ（基本ソフト）が提供するグラフィックエンジン１００２をコールする。
【０００５】
グラフィックエンジン１００２は、例えば、Windows（登録商標）（米国マイクロソフト社の登録商標）では、ＧＤＩ(Graphic Device Interface)と呼ばれておりディスプレイやプリンタに対する画像情報の処理を司っている。
【０００６】
グラフィックエンジン１００２は、プリンタ１００４の種類に合わせて用意されたプリンタドライバ１００３をロードし、アプリケーション１００１の出力をプリンタドライバ１００３に受け渡す。
【０００７】
そして、アプリケーション１００１から受け取るＧＤＩ(Graphic Device Interface)関数からＤＤＩ(Device Driver Interface)関数に変換して、プリンタドライバ１００３へＤＤＩ関数を出力する。
【０００８】
プリンタドライバ１００３は、グラフィックエンジン１００２から受け取ったＤＤＩ関数に基づいて、プリンタが認識可能なプリンタ制御コマンド、例えばＰＤＬ(Page Description Language)等の中間フォーマットに変換する。そして、プリンタドライバ１００３は変換されたプリンタ制御コマンドをプリンタ１００４へ印刷データとして出力する。
【０００９】
プリンタ１００４ではこの制御コマンドを解釈して、ビットマップデータへ展開し、最終的に紙などの記録媒体に印刷結果が出力される。
【００１０】
また、プリンタドライバ１００３には、上述のようにプリンタ１００４で出力するものの他に、ファイル出力するものもある（以下、ファイル出力系プリンタドライバと呼ぶ）。ここで、ファイル出力とは、プリンタ１００４にデータを送ることが直接的な目的ではなく、ＤＤＩ関数から受け取った描画命令を予め定義された中間フォーマットに変換し、ホストコンピュータ１０００のディスク上に中間フォーマットファイルとして蓄積するのである。
【００１１】
この代表的な中間フォーマットにはＰＤＦ(Portable Document Format)やＳＶＧ(Scalable Vector Graphics)等が存在する。中間フォーマットファイルはホストコンピュータ１０００上のファイルシステム上に保存され、解釈可能な特定のアプリケーションによりホストコンピュータ１０００が備える表示装置上で表示できる。また、ユーザの指示により再びグラフィックエンジン１００２を介してプリンタ１００４で印刷を行うことが可能である。
【００１２】
次に、Windows（登録商標）システムにおける文字描画を行う際の処理について説明する。
【００１３】
図１４は、情報処理装置における文字描画に必要な情報の例を表す模式図である。
【００１４】
図１４は一例であるが、一般的に文字描画コマンドには以下の４つのフォント情報が必要である。
【００１５】
第１のフォント情報は文字コードである。ここで、文字コードは、
文字描画で伝えたいところの文字情報であって、例えばASCII、ShiftJIS、Unicode等、あらかじめ定められたコード体系に従ったコードが用いられる。
【００１６】
第２のフォント情報はフォント属性である。ここで、フォント属性とは、文字描画に対応するフェース名、グリフへの修飾を表すイタリック／ボールド指定有無、文字の大きさを表すポイント数等の情報である。
【００１７】
第３のフォント情報は描画属性である。ここで、描画属性とは、文字の描画位置や、色、クリップの状態等を表す情報である。
【００１８】
第４のフォント情報は、フォントファイルである。ここで、フォントファイルとは、ゴシックや明朝等のフェース名で指定される文字描画形状を表す情報である。また、第４のフォント情報には、内部に文字コード毎の描画形状情報（以下、グリフと呼ぶ）を有する。
【００１９】
フォントファイルの情報方式としては、大きくビットマップフォントとアウトラインフォントに分かれ、TrueType、OpenType等の各種フォーマットが定義されている。フォントファイルの内部情報については、さらに後述する。
【００２０】
そして、これらの情報全てが揃わなければ、ユーザが意図した通りの文字描画は成立しない。しかし、文字描画形状を表す情報であるフォントファイルは、例えば著作権の関係等によって、すべての環境に必要とするフォントファイルが存在する保証はない。
【００２１】
言い換えると、ユーザが文字描画データを作成した環境に存在したフォントファイルが、文字描画が行われる環境で存在しない可能性がある。描画が行われる環境にユーザが意図したフォントファイルが存在しない場合にも、ユーザが意図したフォントファイル、もしくはそれに近い形状のフォントファイルで文字描画を行うために、従来、以下の3つの仕組みが知れている。
【００２２】
第１はフォント置き換え、第２はビットマップ置き換え及び、第３はフォント埋め込みという仕組みである。
【００２３】
以下、それぞれの仕組みを用いた場合の描画結果を示す図１５を参照して、それぞれの仕組みについて説明する。
【００２４】
図１５は、従来の情報処理装置における描画処理を説明する図である。
【００２５】
〔フォント置き換え〕
文字描画実行環境において、フォントの置き換えは、文字描画データ中のフォント属性に近い別のフォントを用いて描画を行う方法である。ここで、別のフォントを指定する方法としては、文字描画を行うアプリケーションが予め定義した変換テーブルを用いる方法、ＯＳやプリンタ等が予め定義した変換テーブルを用いる方法が一般的である。
【００２６】
フォント置き換えは、文字描画データを作成する際に、文字描画コマンド（文字コード、フォント属性、描画属性）を作成するが、最もデータ量の多いフォントファイルは必要ないため文字描画データは小さいという利点がある。一方、フォント置き換えによると、別のフォントファイルを用いるため図１５の右最上段に示すように、ユーザが意図していたものとは違った形状の文字描画が行われる可能性がある。
【００２７】
このため上記処理によれば、意図した文字コードに対応したフォントファイルが文字描画実行環境において存在せず、文字として識別不可能な描画が行われることもある。
【００２８】
例えば、一般的に欧米で用いられているＯＳ上には、日本語フォントファイルは存在しない。そのため、文字描画データを作成した環境が一般的な日本のＯＳ上であり、文字描画を行う環境が一般的な欧米のＯＳ上であった場合、文字コードに対応したフォントファイルが存在せず、結果として識別不可能な描画が行われてしまう。
【００２９】
〔ビットマップ置き換え〕
ビットマップ置き換えは、文字描画データを作成する時点で文字描画をビットマップに変換して、文字描画をビットマップ描画に変換する方法である。通常の見た目はユーザが意図した文字描画と同じになる。しかしビットマップであるために図１５右中段に示すように拡大／縮小時にビットマップの解像度の影響で文字品位が落ちる場合がある。
【００３０】
〔フォント埋め込み〕
フォント埋め込みは、文字描画データ内に、文字描画コマンド（文字コード、フォント属性、描画属性）以外に、フォントファイルを埋め込ませ、文字描画が実際に行われる環境まで持っていく方法である。埋め込まれたフォントファイルは、文字描画データ内に含まれるため、文字描画を行う環境において、ユーザが意図した形式で文字描画される。フォント埋め込みは文字描画データ内の文字描画コマンドで指定されたフォントがＯＳ上になくても、ユーザが意図した出力を得られるという利点がある。しかし、フォントファイルを文字描画データに内に埋め込むため、文字描画データが大きくなる傾向にある。特に日本語フォントのような文字種の多いフォントを埋め込む場合にこの問題が顕著である。
【００３１】
次にフォントファイルの内部情報について、図１６を用いて説明する。フォントファイルには主に以下の情報が含まれる。
【００３２】
図１６は、情報処理装置におけるフォントファイルのデータ構造を説明する図である。
【００３３】
図１６において、フェース名は使用するフォントファイルを識別するための識別名である。
【００３４】
グリフ定義数は、フォントファイル内に定義されている「文字の形状を表すグリフ」の数を示し、本例では「１００」の場合を示す。グリフインデックステーブルは、1つのフォントファイルで様々な文字コードに対応するために、TrueTypeやOpenType等のフォントファイルでは、フォントファイル中の個々のグリフに対して文字コードに依存しないようにグリフを管理している。
【００３５】
一般にこのグリフの識別子をグリフインデックスと呼ぶ。それぞれの文字コード体系に対して、文字コードと対応するグリフインデックスとの対応表をグリフインデックステーブルと呼ぶ。
【００３６】
図１６に示す例では、２つのグリフインデックステーブル（UnicodeとShiftJIS）が示されている。一般的なグリフインデックステーブルでは、文字コードからグリフインデックスを特定できるデータ形式となっている。
【００３７】
グリフは、上述しているように文字の形状を表す情報である。グリフを表す方法としては、ビットマップ、パス、曲線等の形式がある。定義された各々のグリフは、フォント内ではフォント依存のグリフインデックスによって識別される。
【００３８】
グリフインデックスはフォント依存であるため、図１６に示すように、「A」のグリフインデックスが、「ゴシック」フォントでは0x0001、「明朝」フォントでは、0x0010と、通常同じ文字でもフォントファイルによってグリフインデックスは異なる。
【００３９】
また、図１６の「明朝フォント」における「£」（イギリスポンド）のように、フォントファイルによっては、グリフが定義されていない文字も存在する。そのような文字を印刷しようとした場合、図１４の右側に示すように、指定したフォントによって「・」や「□」等のグリフ不定義の文字を表す文字が描画される。
【００４０】
ところで、例えば内部文字コードとしてShiftJISしかサポートしていないＯＳの場合、イギリスポンドのグリフが定義されている「ゴシック」フォントであっても、ShiftJISでの文字コードの定義が存在せず、イギリスポンドが表示できない。
【００４１】
ＯＳの商業利用上のためには£（イギリスポンド）やユーロ記号のように一般的な文字が表示できないことは好ましくない。そのため、フォント依存のグリフインデックスを文字コードのかわりに使用し、文字描画のための情報を指定するＯＳやアプリケーションが存在する。その仕組みについて説明する。
【００４２】
図１３に戻って、アプリケーション１００１は、GDIを介し、Unicodeを用いて、ShiftJISでは表現できない文字描画をグラフィックエンジン１００２に対して命令する。グラフィックエンジン１００２は、ＯＳ内部でUnicodeを使用できないために、Unicodeで指定された文字のフォントに対応するグリフインデックステーブルを参照し、テーブル中に含まれるUnicodeに対応するグリフインデックスに変換する。
【００４３】
更にグラフィックエンジン１００２は、グリフインデックスを文字描画の文字コードとしてプリンタドライバ１００３に渡す。プリンタドライバ１００３は、グラフィックエンジン１００２に対してグリフインデックスを指定して文字グリフの取得を行う。グラフィックエンジン１００２は、指定されたグリフインデックスのグリフをフォントファイルより取得し、プリンタドライバ１００３へ受け渡す。プリンタドライバ１０００３は、受け取ったグリフを元に、文字描画コマンドを生成する。
【００４４】
この処理の流れはOSがグラフィックエンジン１００２にてグリフインデックス変換を行うものであるが、アプリケーション１００１が文字出力のGDIをコールする際に、Unicodeではなく、グリフインデックスを指定する事も可能である。その場合の処理は次のようになる。
【００４５】
アプリケーション１００１がフォントファイルを解析し、Unicodeに対応するグリフインデックスを取得し、GDIを介して文字描画を依頼してくる。グラフィックエンジン１００２は、グリフインデックスを文字描画の文字コードとしてプリンタドライバ１００３に渡す。
【００４６】
プリンタドライバ１００３は、グラフィックエンジン１００２に対してグリフインデックスを指定して文字グリフの取得を行う。グラフィックエンジン１００２は、指定されたグリフインデックスのグリフをフォントファイルより取得し、プリンタドライバ１００３へ受け渡す。
【００４７】
プリンタドライバ１００３は、受け取ったグリフを元に、文字描画コマンドを生成する。
【００４８】
ここで、グリフインデックス変換を行うのが、アプリケーション１００１であるかOSであるかにかかわらず、プリンタドライバ１００３に対して、文字描画命令にグリフインデックスが指定されてくる場合の印字方法をグリフインデックス印字と呼ぶ。
【００４９】
また、プリンタドライバ１００３に対して、文字描画命令にUnicodeが指定されてくる場合の印字方法をUnicode印字と呼ぶ。
【００５０】
従来の印刷制御装置においては、グリフインデックス印字時に次のような課題があった。
【００５１】
ここで、情報処理装置は、プリンタに送信する印刷データを生成する前に、中間フォーマットで一時保存を行うスプーラを備えているものとする。さらに、情報処理装置は、上記中間フォーマットデータから改めて最終的にプリンタに送付する印刷データを生成するデスプーラとプリンタ制御コマンドを生成するプリンタドライバを備えるものとする。このような情報処理装置においては、文字コードの代わりフォントに依存したグリフを識別するコード（グリフインデックス）が用いられた場合、デスプーラでフォント置き換えが発生した際に文字化けが発生するおそれがある。
【００５２】
また、プリンタ内蔵フォントで使用可能な文字コードへ変換できず、プリンタ内蔵フォントへの置き換え処理を適用できない。また、このような問題を解決するために、フォント置き換えではなく文字描画をビットマップ描画に置き換えて処理したとしても、デスプーラでの拡大時の文字品位が低下する場合があった。
【００５３】
さらに、色処理、圧縮処理が適用できない、プリンタ内蔵フォントへの置き換えが不可能である等の問題もあった。更に、ファイル出力系のプリンタドライバにおいて、生成した中間フォーマット内のテキスト情報を検索できないという場合もあった。
【００５４】
また、情報処理装置のディスク上に中間フォーマットファイルとして蓄積することを目的とした中間フォーマットの多くは、文字コードを保持するフォーマットを採用している。そうすることで、中間フォーマットファイルを扱うアプリケーションに、文字の検索等の機能を搭載する事ができるためである。
【００５５】
しかしながら、情報処理装置上のプリンタドライバを介して、アプリケーション文書から中間フォーマットファイルを生成する場合、グリフインデックス印字が為されてしまうと、文字コード情報が取得できずアプリケーションにおいて文字検索機能が使えないという場合があった。
【００５６】
このような問題点を解決するために、グリフインデック印字がなされた場合、グリフインデックスに対応する文字コードを取得し、その文字コードを用いて中間フォーマットファイルを生成する方法が提案されている（例えば、特許文献１参照）。
【００５７】
この方法によれば、グリフインデックスを文字コードに変換してからスプール、またはファイル出力することにより、アプリケーションが指定してきた文字コードの情報を失うことなく中間フォーマットファイルを生成できる。
【００５８】
その結果、その後フォント置き換えが発生した場合でも文字化けが起こらず、ユーザが意図した文字を印刷することが可能になるほか、一般的な文字コードを用いた描画の際の、色処理、圧縮、プリンタ内蔵フォント置き換えの処理を文字描画に適用可能になる。
【００５９】
また、ファイル出力の場合、文字コード情報を中間フォーマットファイル内に格納することが可能となり、アプリケーションにおける文字検索機能が使用できるようになる。
【００６０】
図１７〜図１９を用いて、従来の情報処理装置における文字処理について詳しく説明する。
【００６１】
図１７は、従来の情報処理装置におけるアプリケーション文書の一例を示す模式図である。
【００６２】
図１７において、元文書Ａは、図１６で示したゴシックフォントの「ABC渡辺」という文字を含む文書である。この文書をグリフインデックス印字にて中間フォーマットに変換すると、図１８、図１９で示すような中間フォーマットが生成される。図１８，図１９は前述のフォント埋め込み技術に該当する。
【００６３】
図１８は、情報処理装置で扱う中間フォーマットファイルの一つであるＰＤＦファイル内の構造を説明する模式図である。ただし、図１８はＰＤＦの仕様を正確に表したものではない。
【００６４】
図１８において、文字描画命令コマンド５０１で示す部分は、描画する文字のフォント種やフォントサイズ、描画位置、グリフインデックスを記述しており、ここで指定されたフォント種「F1」の情報はフォント情報部５０２に記述されている。
【００６５】
また、グリフインデックスで指定された文字の実体であるグリフはフォントグリフ部５０４に格納されている。また、アプリケーションにおける文字検索機能が使用できるようにするための文字コード情報として、グリフインデックスとUnicodeの関係を記述するToUnicode部５０３が含まれる。
【００６６】
アプリケーションはこのToUnicode部５０３に格納されている情報を元に文字検索機能を実現するのが一般的である。
【００６７】
従来技術では、グリフインデックス印字時、グリフインデックスに対応する文字コードを取得し、その文字コードをToUnicode部５０３に格納することによって、アプリケーションにおける文字検索機能を使用可能とするのである。
【００６８】
図１９は、図１８で示した中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示した図である。
【００６９】
図１９によれば、図１７で示した元文書Ａと同じ文字コードが格納されていることがわかる。
【特許文献１】特開2003-015850号公報
【発明の開示】
【発明が解決しようとする課題】
【００７０】
フォントファイルには、複数の文字コードで1つのグリフ（文字形状）を共通に使用するものが存在する。グリフインデックステーブルで言えば、複数の文字コードが同一のグリフインデックスを指しているフォントファイルがある、という事である。
【００７１】
このようなフォントファイルの場合、グリフインデックス印字が実行されると、従来技術では次のような課題がある。
【００７２】
すなわち、グリフインデックスから該当文字コードを取得しようとしても、候補が複数あるためプリンタドライバ側からでは、どの文字コードがアプリケーションの意図したものであるか判断できない。そのため、アプリケーション文書で検索可能であった文字が中間フォーマットファイルに変換した場合に検索不可能になる場合がある。
【００７３】
図１６の「明朝」フォントを例にとると、「辺」と「邊」は異なる文字コードであるが、同一のグリフインデックス「0x0003」を指している。アプリケーションが、「明朝」フォントの「辺」をグリフインデックス印字にて印刷を実行した際、プリンタドライバには、「明朝」フォント、グリフインデックス「0x0003」という情報が伝えられる。しかし、文字コード情報は送られてこない。
【００７４】
プリンタドライバからすると、「0x0003」に該当する文字コードが「辺」、「邊」の２つ存在する事になり、アプリケーションがどちらの文字コードにて印刷してきたか判断する事ができない。
【００７５】
この結果、生成した中間フォーマットファイルにおいて、該当文字はグリフが同じであるため見た目は問題ない。
【００７６】
しかし、実際に格納されている文字コード（ToUnicode部５０３に格納されている値）がアプリケーションの意図したものではなくなる場合があり、検索機能が正常に動作しないという課題がある。
【００７７】
図２０、図２１を用いてもう少し詳しく説明する。
【００７８】
図１７で示した元文書Ｂは、図１６で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表した図である。
【００７９】
このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換すると、従来技術では、図２０、図２１で示すような中間フォーマットが生成できる。
【００８０】
図２０、図２１は、図１８、図１９と同様にそれぞれ中間フォーマットファイルの一つであるＰＤＦファイル内の構造を説明する模式図である。本例は、中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものを示す例である。
【００８１】
図２０において、グリフインデックスとUnicodeの関係を記述するToUnicode部７０３のうち、グリフインデックス「0x0003」に「0x908A」が格納されている。「明朝」フォントの「辺」をグリフインデックス印字にて印刷を実行した際、プリンタドライバからすると、「0x003」に該当する文字コードが「辺（0x8FBA）」、「邊(0x908A)」の２つ存在する。
【００８２】
そのため、アプリケーションがどちらの文字コードにて印刷してきたか判断できないために起り得る現象である。
【００８３】
図２１によれば、図１７で示した元文書Bとは異なる文字コードが格納されていることがわかる。これにより元文書Ｂでは「辺（0x8FBA）」の文字コードで検索できたが、中間フォーマットファイル上では検索できなくなってしまうのである。これはToUnicode部７０３に格納されている文字コードが「邊(0x908A)」となっているためである。
【００８４】
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、複数の文字コードが１つのグリフ（文字形状）を共通に使用している文字でも，中間フォーマットファイル内にアプリケーションが元々保持していた文字コードを格納できる仕組みを提供することである。
【課題を解決するための手段】
【００８５】
上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。
【００８６】
アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置であって、前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する文字コードを取得する取得手段と、前記取得手段により取得する１つのグリフインデックスに対して複数の文字コードから選択される１つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当て手段と、前記割り当て手段により前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理手段とを有することを特徴とする。
【発明の効果】
【００８７】
複数の文字コードが１つのグリフ（文字形状）を共通に使用している文字でも，中間フォーマットファイル内にアプリケーションが元々保持していた文字コードを格納する事ができる。また、アプリケーションの検索処理を一切変更することなく，アプリケーションが元々保持していた文字コードで文字を検索する事が可能になる。
【発明を実施するための最良の形態】
【００８８】
次に本発明を実施するための最良の形態について図面を参照して説明する。
【００８９】
＜システム構成の説明＞
〔第１実施形態〕
図１Ａは、本実施形態を示す情報処理装置の構成を説明するブロック図である。本例は、一般的なコンピュータである情報処理装置１００の内部システムに対応する。以下、情報処理装置１００において、アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する処理を説明する。
【００９０】
図１Ａにおいて、ＣＰＵ１０１はＲＯＭ１０２あるいはＲＡＭ１０３あるいは外部記憶装置１０５に格納されたプログラムに従って装置全体の制御を行う。
【００９１】
ＲＡＭ１０３はＣＰＵ１０１が各種処理を行う際のワークエリアとして使用される。外部記憶装置１０５はオペレーティングシステム（ＯＳ）やアプリケーションソフト、プリンタドライバソフト等を記録する。
【００９２】
キーボード１０４もしくは図示していないマウスなどの入力機器は、ユーザが各種指示を与えるためのデバイスである。
【００９３】
ネットワークＩ／Ｆ１０６およびプリンタＩ／Ｆ１０７はイーサネット（登録商標）１１２または専用インターフェース１１１を介してプリンタと接続し、データの授受を行うためのインターフェースである。
【００９４】
モニタＩ／Ｆ１０８はモニタに接続し表示データの転送を行うためのインターフェースである。また、１１０は共通データバスである。
【００９５】
以下、図１Ｂを参照して情報処理装置における印刷処理を説明する。
【００９６】
図１Ｂは、図１Ａに示した情報処理装置における印刷システムのモジュール構成を説明するブロック図である。本例は、情報処理装置１００のＲＡＭ１０３にロードされたプログラムモジュールに対応する。
【００９７】
図１Ｂにおいて、アプリケーション１０５Ｂ、グラフィックエンジン１０５Ｄ、プリンタドライバ１０５Ｃは、外部記憶装置１０５に保存されたファイルとして存在する。そして、これらは、ＯＳ１０５Ａやそのモジュールを利用するモジュールによってＲＡＭ１０３にロードされて実行されるプログラムモジュールである。
【００９８】
また、アプリケーション１０５Ｂおよびプリンタドライバ１０５Ｃは、外部記憶装置１０５のＦＤや不図示のＣＤ−ＲＯＭ、あるいは不図示のネットワークを経由して外部記憶装置１０５のＨＤに追加することが可能となっている。
【００９９】
アプリケーション１０５Ｂからプリンタ１００４（図１３）に対して印刷を行う際には、グラフィックエンジン１０５Ｄを利用して出力（描画）を行う。ユーザはプリンタごとに用意されたプリンタドライバ１０５Ｃを、アプリケーション１０５Ｂの出力先として設定する。
【０１００】
ユーザはさらにアプリケーション１０５Ｂ上で、必要に応じてあらかじめ印刷出力に関わる印刷設定を行う。ユーザはアプリケーション１０５Ｂ、もしくはプリンタドライバの有するユーザインタフェースを通じて設定値を入力することができる。以降の処理の流れは既に説明しているため、ここでは省略する。
【０１０１】
なお、本実施形態ではプリンタドライバは、PDFやSVG等を作成するファイル出力系のプリンタドライバとして説明するが、本発明はプリンタ出力するためのPDLを作成するプリンタドライバにも適用できる。
【０１０２】
＜中間フォーマットファイル生成処＞
図２は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、中間フォーマットファイルを生成する処理例である。Ｓ８０１〜Ｓ８１０は各ステップを示し、各ステップは、ＣＰＵ１０１がＲＡＭ１０３上にアプリケーション、プリンタドライバをロードして実行することで実現される。
【０１０３】
本処理は、ユーザから印刷指示を受け付けたアプリケーション１０５Ｂは、グラフィックエンジン１０５Ｄを介してプリンタドライバ１０５Ｃに、印刷対象ファイルを中間フォーマットへ変換する要求を出すと開始される。
【０１０４】
まず、Ｓ８０１で、アプリケーション１０５Ｂは、変換ジョブが開始することを、ＧＤＩ関数を介してグラフィックエンジン１０５Ｄに通知する。グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。
【０１０５】
次に、Ｓ８０２で、プリンタドライバ１０５Ｃは、ジョブ開始コマンドを生成する。そして、Ｓ８０３で、アプリケーション１０５Ｂはページが開始することを、ＧＤＩ関数を介してグラフィックエンジン１０５Ｄに通知する。次に、Ｓ８０４で、グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。プリンタドライバ１０５Ｃは、ページ開始コマンドを生成する。
【０１０６】
そして、Ｓ８０５で、アプリケーション１０５Ｂは論理描画要求を、GDI関数を介してグラフィックエンジン１０５Ｄに通知する。グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。
【０１０７】
次に、Ｓ８０６で、プリンタドライバ１０５Ｃは、論理描画コマンドを生成する。Ｓ８０７で、アプリケーション１０５Ｂは、ページの終了要求が通知されるまで、Ｓ８０５、Ｓ８０６の処理を繰り返す。そして、ページ終了要求が通知されたら、アプリケーション１０５Ｂが、ページが終了することを、ＧＤＩ関数を介してグラフィックエンジン１０５Ｄに通知する。そして、Ｓ８０８で、グラフィックエンジン１０５Ｄが通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡すと、プリンタドライバ１０５Ｃは、ページ終了コマンドを生成する。
【０１０８】
そして、Ｓ８０９で、アプリケーション１０５Ｂからのジョブ終了要求が通知されるまで、Ｓ８０５〜Ｓ８０８を繰り返して、アプリケーション１０５Ｂが、ジョブが終了することを、ＧＤＩ関数を介してグラフィックエンジンに通知する。
【０１０９】
そして、Ｓ８１０で、グラフィックエンジン１０５Ｄが通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡すと、プリンタドライバ１０５Ｃは、ジョブ終了コマンドを生成して、本処理を終了する。
【０１１０】
＜文字描画の処理手順＞
図３は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、Ｓ８０５，Ｓ８０６に対応する文字描画処理例である。Ｓ９０１〜Ｓ９１５は各ステップを示し、各ステップは、ＣＰＵ１０１がＲＡＭ１０３上にアプリケーション、プリンタドライバをロードして実行することで実現される。
【０１１１】
なお、S９０１はアプリケーション１０５Ｂおよびグラフィックスエンジン１０５Ｄで行われるステップＳ８０５の一部であり、ステップＳ９０２〜Ｓ９１５はプリンタドライバ１０５Ｃで行われるステップＳ８０６の一部である。グラフィックスやイメージについても同様に描画処理が行われるが、図３ではそれらは省略している。
【０１１２】
まず、Ｓ９０１で、アプリケーション１０５Ｂは文字描画要求を出す際、ＧＤＩ関数を用いて文字コード、フォント属性、描画属性もしくは、グリフインデックス、フォント属性、描画属性をグラフィックエンジン１０５Ｄに通知する。そして、グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。
【０１１３】
次に、Ｓ９０２で、プリンタドライバ１０５Ｃは、ＧＤＩ関数のパラメータとして受け取ったフォント属性に含まれるフォントフェース名をもとにして、フォントファイルをシステム（ＯＳ）から読み込む。そして、Ｓ９０２で、プリンタドライバ１０５Ｃは、フォントファイル内に含まれるグリフインデックステーブルを取得する。
【０１１４】
次に、プリンタドライバ１０５Ｃは、Ｓ９０１にてアプリケーション１０５Ｂから送られてきた描画命令に文字コードが含まれていればUnicode印字と判断してＳ９０５へ移行する。逆に、グリフインテックスが含まれていればグリフインデックス印字と判断してＳ９０８へ移行する（Ｓ９０４）。
【０１１５】
そして、Ｓ９０５では、プリンタドライバ１０５Ｃは、Ｓ９０３にて取得したグリフインデックステーブルを利用して、Ｓ９０１で受け取った文字コードに該当するグリフインデックスを取得する。次に、Ｓ９０６で、プリンタドライバ１０５Ｃは、グリフインデックスから文字形状情報を示すグリフを取得する。
【０１１６】
そして、Ｓ９０７で、プリンタドライバ１０５Ｃは、Ｓ９０１で受け取った文字コード、フォント属性、描画属性、Ｓ９０５にて取得したグリフインデックス、Ｓ９０６にて取得したグリフを用いて、中間フォーマットに沿った文字描画コマンドを生成して、処理を終了する。
【０１１７】
Ｓ９０４にて、グリフインデックス印字と判断された場合、Ｓ９０８で、プリンタドライバ１０５Ｃは、Ｓ９０３にて取得したグリフインデックステーブルから図４に示すグリフインデックス逆引きテーブルを作成する。
【０１１８】
図４、図５は、図１に示したプリンタドライバ１０５Ｃが作成するグリフインデックス逆引きテーブルの一例を示す図である。なお、図４は、更新前のグリフインデックス逆引きテーブルに対応し、図５は更新後のグリフインデックス逆引きテーブルに対応する。
【０１１９】
図４に示す例は、図３で示したグリフインデックステーブルから作成したグリフインデックス逆引きテーブルを示すものである。
【０１２０】
先述の通り、一般的なグリフインデックステーブルは、文字コードからグリフインデックスを引くデータ形式となっているが、ここでは逆にグリフインデックスから文字コードを引く処理テーブルを作成する。
【０１２１】
次に、Ｓ９０９で、プリンタドライバ１０５Ｃは、Ｓ９０８で作成したグリフインデックス逆引きテーブルを利用して、Ｓ９０１で受け取ったグリフインデックスに該当する文字コードを取得する。
【０１２２】
この文字コードを取得する際、文字コード候補が複数ある場合、候補の中で一番大きい値の文字コード１つを取得する。これは、先述の通りフォントファイルには、複数の文字コードが１つのグリフを共通に使用するものが存在するためである。
【０１２３】
具体的には、図４に示す「明朝」フォントの例ではグリフインデックス0x0003のように、グリフインデックスに対して文字コードが複数割り当っている場合、文字コード0x908Aがこれに該当する。なお、実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に問わない。
【０１２４】
次に、Ｓ９１０で、プリンタドライバ１０５Ｃは、Ｓ９０１で受け取ったグリフインデックスから文字形状情報を示すグリフを取得する。次に、Ｓ９１１で、プリンタドライバ１０５Ｃは、Ｓ１０１で受け取ったグリフインデックス、フォント属性、描画属性、Ｓ９０９にて取得した文字コード、Ｓ９１０にて取得したグリフを用いて、中間フォーマットに沿った文字描画コマンドを生成する。
【０１２５】
次に、Ｓ９１２で、プリンタドライバ１０５Ｃは、Ｓ９０９にて文字コードを取得する際に、当該グリフインデックスに割り当てられた文字コード候補が複数あるかどうかを判断する。ここで、当該グリフインデックスに割り当てられた文字コード候補が複数あるとプリンタドライバ１０５Ｃが判断した場合は、Ｓ９１３へ移行し、一つしかないとプリンタドライバ１０５Ｃが判断した場合は、本処理を終了する。
【０１２６】
次に、Ｓ９１３で、プリンタドライバ１０５Ｃは、グリフインデックス逆引きテーブルを解析し、文字コードの割り当っていないグリフインデックス（空のグリフインデックス）を探索し、その値を保持する。
【０１２７】
図４に示す「明朝」フォントの例にすると、0x0070や0x0071や0x0072が文字コードの割り当っていないグリフインデックスに該当する。つまり、プリンタドライバ１０５Ｃは、取得する１つのグリフインデックスに対して複数の文字コードから選択される１つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる。これにより、アプリケーションが元々保持している文字コードで文字検索を行うことができる。
【０１２８】
次に、Ｓ９１４で、プリンタドライバ１０５Ｃは、Ｓ９１３で取得した未使用のグリフインデックスに、Ｓ９１１で出力した文字コード以外の文字コード候補の中で、一番大きい値の文字コードを割り当てる。
【０１２９】
図４に示す「明朝」フォントの例にすると、グリフインデックス0x070に対して、Unicode 0x8FBAを割り当て、「明朝」フォントのグリフインデックス逆引きテーブルを図５に示すように更新するのである。尚、本実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に方法は問わない。
【０１３０】
次に、Ｓ９１５で、プリンタドライバ１０５Ｃは、Ｓ９１３で取得したグリフインデックス、Ｓ９１４にて取得した文字コード、Ｓ９１０にて取得したグリフ、Ｓ９０１で受け取ったフォント属性、描画属性を用いて、中間フォーマットに沿った文字描画コマンドを生成する。尚、ここでは、Ｓ９０１から受け取った描画属性のうち色に関する情報を無視し、透明属性で文字描画コマンドを生成するものとする。また、Ｓ９１２〜Ｓ９１５の処理は、Ｓ９０９にて取得したすべての文字コード候補に対して処理を行うまで繰り返す。
【０１３１】
このような手順で作成できる中間フォーマットファイルについて、図６、図７を用いて説明する。
【０１３２】
なお、図１７で示した元文書Ｂは、図１６で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表していることは上述した通りである。このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換する際、図２、図３のフロー図で示した手順を踏むことよって、図６、図７で示すような中間フォーマットファイルが生成できる。
【０１３３】
図６は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。本例は、図６に示す中間フォーマットファイルの一つであるＰＤＦファイル内の構造を模式的に表したものである。
【０１３４】
図７は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの表示例を示す図である。本例は、中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものである。
【０１３５】
図６において、グリフインデックスとUnicodeの関係を記述するToUnicode部１３０３のうち、グリフインデックス「0x0003」に「0x908A」が、「0x0070」に「0x8FBA」がそれぞれ格納されている。また文字描画命令コマンド１３０１で示す部分には、描画する文字としてグリフインデックス「0x0003」の他に、透明属性の文字として「0x0070」が描画されている。
【０１３６】
また、図７によれば、図１６で示した元文書Bとは異なる文字コード「0x908A」の他に、「0x8FBA」が格納されていることがわかる。これにより中間フォーマットファイル上でも元文書Bで検索可能であった「0x8FBA」を検索できるようになるのである。
【０１３７】
〔第２実施形態〕
第２実施例においては、文字描画の処理手順（図３で説明した手順）が第１実施形態と異なる。第１実施形態では、一つのグリフインデックスに複数の文字コードが割当たっているようなフォントファイルにおけるグリフインデックス印字の際に、「文字単位」で文字を透明出力する描画コマンドを生成するものである。
【０１３８】
図７で示したように、「ＡＢＣ渡辺」という文字に対して、「0x0041, 0x0042, 0x0043, 0x6E21, 0x908A」と、「0x8FBA」，という文字コード情報を内部に保持している。
【０１３９】
この文字コード情報によりアプリケーションから「辺（0x8FBA）」の文字コードでの検索が可能になる。しかしながら、この方法では、アプリケーションから文字列検索を行う場合に、「渡邉（0x6E21, 0x908A）」での検索は可能であるが、「渡辺（0x6E21, 0x8FBA）」での検索ができない。
【０１４０】
そこで、第２実施形態では、文字列単位で透明出力する文字列描画コマンドの生成する方法を示す。その他の処理や構成については第１実施形態と同じであるため説明は省略する。以下、図２に示したＳ８０５，Ｓ８０６における論理描画処理の内、文字列描画コマンドについて図８に示すフローチャートを用いた処理について説明する。
【０１４１】
＜文字列描画の処理手順＞
図８は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は文字列描画処理例である。Ｓ１６０１〜Ｓ１６１８は各ステップを示し、各ステップは、ＣＰＵ１０１がＲＡＭ１０３上にアプリケーション、プリンタドライバをロードして実行することで実現される。図８において、Ｓ１６０１はアプリケーション１０５Ｂおよびグラフィックスエンジン１０５Ｄで行われるＳ８０５の一部である。また、Ｓ１６０２〜Ｓ１６１８はプリンタドライバ１０５Ｃで行われるＳ８０６の一部である。グラフィックスやイメージについても同様に描画処理が行われるが、図８ではそれらは省略している。
【０１４２】
Ｓ１６０１で、アプリケーション１０５ＢはＧＤＩ関数を介して、文字列描画要求を出す際、各文字の文字コード、フォント属性、描画属性もしくは、グリフインデックス、フォント属性、描画属性をグラフィックエンジン１０５Ｄに通知する。グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。
【０１４３】
次に、Ｓ１６０２で、プリンタドライバ１０５Ｃは、ＧＤＩ関数のパラメータとして受け取ったフォント属性に含まれるフォントフェース名をもとにして、フォントファイルをシステム（ＯＳ）から読み込む。そして、Ｓ１６０３で、プリンタドライバ１０５Ｃは、フォントファイル内に含まれるグリフインデックステーブルを取得する。
【０１４４】
次に、Ｓ１６０４で、プリンタドライバ１０５Ｃは、Ｓ１６０１にてアプリケーション１０５Ｂから送られてきた描画命令に文字コードが含まれていればUnicode印字と判断した場合は、Ｓ１６０５へ移行する。Ｓ１６０４で、逆に、グリフインテックスが含まれているとプリンタドライバ１０５Ｃが判断した場合は、グリフインデックス印字と判断してＳ１６０８へ移行する。
【０１４５】
Ｓ１６０５で、プリンタドライバ１０５Ｃは、Ｓ１６０３にて取得したグリフインデックステーブルを利用して、Ｓ１６０１で受け取った文字列それぞれの文字コードに該当するグリフインデックスを取得する。
【０１４６】
次に、Ｓ１６０６で、プリンタドライバ１０５Ｃは、各グリフインデックスから文字形状情報を示す各グリフを取得する。そして、Ｓ１６０７で、プリンタドライバ１０５Ｃは、文字列描画コマンドを生成して、処理を終了する。
【０１４７】
具体的には、Ｓ１６０１で受け取った文字列の文字コード、フォント属性、描画属性、Ｓ１６０５にて取得したグリフインデックス、Ｓ１６０６にて取得したグリフを用いて、中間フォーマットに沿った文字列描画コマンドを生成する。
【０１４８】
一方、Ｓ１６０４にて、グリフインデックス印字とプリンタドライバ１０５Ｃが判断した場合は、以下のＳ１６０８以降の処理を実行する。
【０１４９】
Ｓ１６０８で、プリンタドライバ１０５Ｃは、Ｓ１６０３にて取得したグリフインデックステーブルからグリフインデックス逆引きテーブルを作成する。なお、グリフインデックス逆引きテーブルの例は図４で説明したためここでの説明は省略する。
【０１５０】
次に、Ｓ１６０９で、プリンタドライバ１０５Ｃは、文字列のすべての文字に対して処理を実行したかどうかを判断する。ここで、文字列のすべての文字に対して処理を実行していないとプリンタドライバ１０５Ｃが判断した場合は、Ｓ１６１０へ進む。そして、Ｓ１６１０で、プリンタドライバ１０５Ｃは、Ｓ１６０８で作成したグリフインデックス逆引きテーブルを利用して、Ｓ１６０１で受け取ったグリフインデックスに該当する文字コードを取得する。この文字コードを取得する際、文字コード候補が複数ある場合、候補の中で一番大きい値の文字コード１つを取得する。具体的には、グリフインデックス逆引きテーブル内に、当該グリフインデックスに対して文字コードが複数割り当っている場合、図４の「明朝」フォントの例ではグリフインデックス0x0003がこれに該当する。
【０１５１】
なお、本実施例では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に問わない。
【０１５２】
次に、Ｓ１６１１で、プリンタドライバ１０５Ｃは、Ｓ１６０１で受け取ったグリフインデックスから文字形状情報を示すグリフを取得する。
【０１５３】
次に、Ｓ１６１２で、プリンタドライバ１０５Ｃは、Ｓ１６０１で受け取ったグリフインデックス、フォント属性、描画属性、Ｓ１６１０にて取得した文字コード、Ｓ１６１１にて取得したグリフの情報を文字列キャッシュテーブルに格納しておく。
【０１５４】
図９は、本実施形態を示す情報処理装置で管理される文字列キャッシュテーブルの一例を示す図である。ここでは、文字描画コマンドの生成に必要な情報である、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、の情報を文字列キャッシュテーブルに格納する。
【０１５５】
次に、Ｓ１６１３で、プリンタドライバ１０５Ｃは、Ｓ１６１０にて文字コードを取得する際に、当該グリフインデックに割り当てられた文字コード候補が複数あると判断した場合、Ｓ１６１４へ移行する。また、当該グリフインデックに割り当てられた文字コード候補が一つしかないとプリンタドライバ１０５Ｃが判断した場合は、Ｓ１６０９へ移行する。
【０１５６】
次に、Ｓ１６１４で、プリンタドライバ１０５Ｃは、グリフインデックス逆引きテーブルを解析し、文字コードの割り当っていないグリフインデックスを探索し、その値を保持する。図４に示す「明朝」フォントの例にすると、0x0070や0x0071が文字コードの割り当っていないグリフインデックスに該当する。
【０１５７】
次に、Ｓ１６１５で、プリンタドライバ１０５Ｃは、Ｓ１６１４で取得した未使用のグリフインデックスに、Ｓ９１１で出力した文字コード以外の文字コード候補の中で、一番大きい値の文字コードを割り当てる。また、プリンタドライバ１０５Ｃは、Ｓ１６１４、Ｓ１６１５で取得したグリフインデックスと、該当グリフインデックスに割り当てられたUnicodeを文字列キャッシュテーブルの透明出力グリフインデックス、透明出力文字コードにそれぞれ格納し保持させておく。
【０１５８】
図４に示す「明朝」フォントの例にすると、グリフインデックス0x070に対して、Unicode 0x8FBAを割り当て、「明朝」フォントのグリフインデックス逆引きテーブルを図５に示すように更新するのである。なお、本実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に方法は問わない。
【０１５９】
プリンタドライバ１０５Ｃは、文字列に含まれる文字すべてに対してＳ１６１０からＳ１６１６までの処理を行い、この時点で、図９に示した文字列キャッシュテーブルが完成したら、Ｓ１６０９からＳ１６１７へ進む。
【０１６０】
次に、Ｓ１６１７で、プリンタドライバ１０５Ｃは、Ｓ１６１６までの処理で生成した文字列キャッシュテーブルに格納されている、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、を元に中間フォーマットに沿った文字描画コマンドを生成する。
【０１６１】
次に、Ｓ１６１８で、プリンタドライバ１０５Ｃは、文字列キャッシュテーブル内に、透明出力グリフインデックス、透明出力文字コードが格納されている場合、透明出力グリフインデックス、透明出力文字コードが格納されていない文字と、格納されている文字を組み合わせて、文字列を生成する。さらに、プリンタドライバ１０５Ｃは、その文字列に含まれる文字の、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、の情報を元に中間フォーマットに沿った文字描画コマンドを透明属性にて生成して、本処理を終了する。ここで、透明属性とは、文字を透明状態で表示する属性であって、この属性を本実施形態において非表示属性と呼ぶ。
【０１６２】
このような手順で作成できる中間フォーマットファイルについて、図１０、図１１を用いて説明する。
【０１６３】
なお、図１７で示した元文書Ｂは、図１６で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表していることは上述した通りである。このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換する際、図２、図８に示すフロー図で示した手順を踏むことよって、図１０、図１１で示すような中間フォーマットが生成できる。
【０１６４】
図１０、図１１は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。ここで、図１０は中間フォーマットファイルの一つであるＰＤＦファイル内の構造を模式的に表したものである。また、図１１は中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものである。
【０１６５】
図１０において、グリフインデックスとUnicodeの関係を記述するToUnicode部１３０３のうち、グリフインデックス「0x0003」に「0x908A」が、「0x0070」に「0x8FBA」がそれぞれ格納されている。また文字描画命令コマンド１３０１で示すテキスト情報の部分には、描画する文字としてグリフインデックス「0x0003」の他に、透明属性の文字として「0x0070」が描画されている。
【０１６６】
また、図１１によれば、図１６で示した元文書Bとは異なる文字コード「0x908A」の他に、「0x8FBA」が格納されていることがわかる。これにより中間フォーマットファイル上でも元文書Bで検索可能であった「0x8FBA」を含む文字列を検索できるようになるのである。
【０１６７】
なお、第１及び第２実施形態ともに、日本語漢字領域の文字コードを例に説明してきたが、中国語や韓国語、欧米文字領域の文字コード等についても本件は適用可能である。
【０１６８】
ここでは欧文フォントを例に説明する。Unicodeでは、アルファベットや「!」や、「-」とった文字に対して、それぞれ全角文字が別に定義されている。
【０１６９】
例えば、欧米で一般的に使われる「Ａ」はUnicodeでは、「0x0041」であるが、全角用「Ａ」のUnicodeは「0xff21」である。また、同様に一般的な「-」は「0x002d」であるが、全角用の「‐」は「0xff0d」である。フォントによっては、上記のような文字コードにおいて、一般的に使わるコードと全角用のコードで同じグリフ（文字形状）を共通に使用するものが存在する。
【０１７０】
グリフインデックステーブルで言えば、例えば「0x0041」と「0xff21」の文字コードが同一のグリフインデックスを指しているフォントファイルがある、ということである。
【０１７１】
このようなフォントファイルにおいて、アプリケーション１０５Ｂから「0x0041」の文字をグリフインデックス印字で描画命令が実行された場合、プリンタドライバ１０５Ｃは、図３で示した手順（特にＳ９０８〜Ｓ９１５）もしくは、図８で示した手順（特にＳ１６０８〜Ｓ１６１８）を踏むことにより、中間フォーマットファイル内に「0xff21」の文字と、「0x0041」の透明文字を格納することが可能となる。これにより中間フォーマットファイル上でも元文書で検索可能であった「0x0041」を検索できるようになるのである。
【０１７２】
以下、図１２に示すメモリマップを参照して本発明に係る情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
【０１７３】
図１２は、本発明に係る情報処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【０１７４】
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１７５】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１７６】
本実施形態におけるフローチャートに示す機能が外部からインストールされるプログラムによって、情報処理装置により遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１７７】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１７８】
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１７９】
従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１８０】
プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【０１８１】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶したコンピュータ読み取り可能な記憶媒体は本発明を構成することになる。
【０１８２】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバやｆｔｐサーバ等も本発明の請求項に含まれるものである。
【０１８３】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１８４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。例えばそのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１８５】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１８６】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。
【０１８７】
本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。
【図面の簡単な説明】
【０１８８】
【図１Ａ】本実施形態を示す情報処理装置の構成を説明するブロック図である。
【図１Ｂ】図１Ａに示した情報処理装置における印刷システムのモジュール構成を説明するブロック図である。
【図２】本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。
【図３】本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。
【図４】図１に示したプリンタドライバ１０５Ｃが作成するグリフインデックス逆引きテーブルの一例を示す図である。
【図５】図１に示したプリンタドライバ１０５Ｃが作成するグリフインデックス逆引きテーブルの一例を示す図である。
【図６】本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。
【図７】本実施形態を示す情報処理装置で扱う中間フォーマットファイルの表示例を示す図である。
【図８】本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。
【図９】本実施形態を示す情報処理装置で管理される文字列キャッシュテーブルの一例を示す図である。
【図１０】本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。
【図１１】本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。
【図１２】本発明に係る情報処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【図１３】従来の印刷システムに係る情報処理装置のモジュール構成を説明するブロック図である。
【図１４】情報処理装置における文字描画に必要な情報の例を表す模式図である。
【図１５】従来の情報処理装置における描画処理を説明する図である。
【図１６】情報処理装置におけるフォントファイルのデータ構造を説明する図である。
【図１７】従来の情報処理装置におけるアプリケーション文書の一例を示す模式図である。
【図１８】情報処理装置で扱う中間フォーマットファイルの一つであるＰＤＦファイル内の構造を説明する模式図である。
【図１９】図１８で示した中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示した図である。
【図２０】情報処理装置で扱う中間フォーマットファイルの一つであるＰＤＦファイル内の構造を説明する模式図である。
【図２１】図２０で示した中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示した図である。
【符号の説明】
【０１８９】
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０５ 外部記憶装置
１０５Ｂ アプリケーション
１０５Ｃ プリンタドライバ
【技術分野】
【０００１】
本発明は、アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置のデータ処理に関するものである。
【背景技術】
【０００２】
図１３は、従来の印刷システムに係る情報処理装置のモジュール構成を説明するブロック図である。本例は、ホストコンピュータ１０００とプリンタ１００４とが直接あるいはネットワーク経由で接続されている印刷システムに対応する。
【０００３】
図１３において、印刷処理は、ホストコンピュータ１０００のユーザが、ワードプロセッサプログラムや表計算プログラム等のアプリケーション１００１から、印刷指示を行うことによって開始する。
【０００４】
アプリケーション１００１は、文字描画データ等を含むアプリケーションデータを解析して、例えばＯＳ（基本ソフト）が提供するグラフィックエンジン１００２をコールする。
【０００５】
グラフィックエンジン１００２は、例えば、Windows（登録商標）（米国マイクロソフト社の登録商標）では、ＧＤＩ(Graphic Device Interface)と呼ばれておりディスプレイやプリンタに対する画像情報の処理を司っている。
【０００６】
グラフィックエンジン１００２は、プリンタ１００４の種類に合わせて用意されたプリンタドライバ１００３をロードし、アプリケーション１００１の出力をプリンタドライバ１００３に受け渡す。
【０００７】
そして、アプリケーション１００１から受け取るＧＤＩ(Graphic Device Interface)関数からＤＤＩ(Device Driver Interface)関数に変換して、プリンタドライバ１００３へＤＤＩ関数を出力する。
【０００８】
プリンタドライバ１００３は、グラフィックエンジン１００２から受け取ったＤＤＩ関数に基づいて、プリンタが認識可能なプリンタ制御コマンド、例えばＰＤＬ(Page Description Language)等の中間フォーマットに変換する。そして、プリンタドライバ１００３は変換されたプリンタ制御コマンドをプリンタ１００４へ印刷データとして出力する。
【０００９】
プリンタ１００４ではこの制御コマンドを解釈して、ビットマップデータへ展開し、最終的に紙などの記録媒体に印刷結果が出力される。
【００１０】
また、プリンタドライバ１００３には、上述のようにプリンタ１００４で出力するものの他に、ファイル出力するものもある（以下、ファイル出力系プリンタドライバと呼ぶ）。ここで、ファイル出力とは、プリンタ１００４にデータを送ることが直接的な目的ではなく、ＤＤＩ関数から受け取った描画命令を予め定義された中間フォーマットに変換し、ホストコンピュータ１０００のディスク上に中間フォーマットファイルとして蓄積するのである。
【００１１】
この代表的な中間フォーマットにはＰＤＦ(Portable Document Format)やＳＶＧ(Scalable Vector Graphics)等が存在する。中間フォーマットファイルはホストコンピュータ１０００上のファイルシステム上に保存され、解釈可能な特定のアプリケーションによりホストコンピュータ１０００が備える表示装置上で表示できる。また、ユーザの指示により再びグラフィックエンジン１００２を介してプリンタ１００４で印刷を行うことが可能である。
【００１２】
次に、Windows（登録商標）システムにおける文字描画を行う際の処理について説明する。
【００１３】
図１４は、情報処理装置における文字描画に必要な情報の例を表す模式図である。
【００１４】
図１４は一例であるが、一般的に文字描画コマンドには以下の４つのフォント情報が必要である。
【００１５】
第１のフォント情報は文字コードである。ここで、文字コードは、
文字描画で伝えたいところの文字情報であって、例えばASCII、ShiftJIS、Unicode等、あらかじめ定められたコード体系に従ったコードが用いられる。
【００１６】
第２のフォント情報はフォント属性である。ここで、フォント属性とは、文字描画に対応するフェース名、グリフへの修飾を表すイタリック／ボールド指定有無、文字の大きさを表すポイント数等の情報である。
【００１７】
第３のフォント情報は描画属性である。ここで、描画属性とは、文字の描画位置や、色、クリップの状態等を表す情報である。
【００１８】
第４のフォント情報は、フォントファイルである。ここで、フォントファイルとは、ゴシックや明朝等のフェース名で指定される文字描画形状を表す情報である。また、第４のフォント情報には、内部に文字コード毎の描画形状情報（以下、グリフと呼ぶ）を有する。
【００１９】
フォントファイルの情報方式としては、大きくビットマップフォントとアウトラインフォントに分かれ、TrueType、OpenType等の各種フォーマットが定義されている。フォントファイルの内部情報については、さらに後述する。
【００２０】
そして、これらの情報全てが揃わなければ、ユーザが意図した通りの文字描画は成立しない。しかし、文字描画形状を表す情報であるフォントファイルは、例えば著作権の関係等によって、すべての環境に必要とするフォントファイルが存在する保証はない。
【００２１】
言い換えると、ユーザが文字描画データを作成した環境に存在したフォントファイルが、文字描画が行われる環境で存在しない可能性がある。描画が行われる環境にユーザが意図したフォントファイルが存在しない場合にも、ユーザが意図したフォントファイル、もしくはそれに近い形状のフォントファイルで文字描画を行うために、従来、以下の3つの仕組みが知れている。
【００２２】
第１はフォント置き換え、第２はビットマップ置き換え及び、第３はフォント埋め込みという仕組みである。
【００２３】
以下、それぞれの仕組みを用いた場合の描画結果を示す図１５を参照して、それぞれの仕組みについて説明する。
【００２４】
図１５は、従来の情報処理装置における描画処理を説明する図である。
【００２５】
〔フォント置き換え〕
文字描画実行環境において、フォントの置き換えは、文字描画データ中のフォント属性に近い別のフォントを用いて描画を行う方法である。ここで、別のフォントを指定する方法としては、文字描画を行うアプリケーションが予め定義した変換テーブルを用いる方法、ＯＳやプリンタ等が予め定義した変換テーブルを用いる方法が一般的である。
【００２６】
フォント置き換えは、文字描画データを作成する際に、文字描画コマンド（文字コード、フォント属性、描画属性）を作成するが、最もデータ量の多いフォントファイルは必要ないため文字描画データは小さいという利点がある。一方、フォント置き換えによると、別のフォントファイルを用いるため図１５の右最上段に示すように、ユーザが意図していたものとは違った形状の文字描画が行われる可能性がある。
【００２７】
このため上記処理によれば、意図した文字コードに対応したフォントファイルが文字描画実行環境において存在せず、文字として識別不可能な描画が行われることもある。
【００２８】
例えば、一般的に欧米で用いられているＯＳ上には、日本語フォントファイルは存在しない。そのため、文字描画データを作成した環境が一般的な日本のＯＳ上であり、文字描画を行う環境が一般的な欧米のＯＳ上であった場合、文字コードに対応したフォントファイルが存在せず、結果として識別不可能な描画が行われてしまう。
【００２９】
〔ビットマップ置き換え〕
ビットマップ置き換えは、文字描画データを作成する時点で文字描画をビットマップに変換して、文字描画をビットマップ描画に変換する方法である。通常の見た目はユーザが意図した文字描画と同じになる。しかしビットマップであるために図１５右中段に示すように拡大／縮小時にビットマップの解像度の影響で文字品位が落ちる場合がある。
【００３０】
〔フォント埋め込み〕
フォント埋め込みは、文字描画データ内に、文字描画コマンド（文字コード、フォント属性、描画属性）以外に、フォントファイルを埋め込ませ、文字描画が実際に行われる環境まで持っていく方法である。埋め込まれたフォントファイルは、文字描画データ内に含まれるため、文字描画を行う環境において、ユーザが意図した形式で文字描画される。フォント埋め込みは文字描画データ内の文字描画コマンドで指定されたフォントがＯＳ上になくても、ユーザが意図した出力を得られるという利点がある。しかし、フォントファイルを文字描画データに内に埋め込むため、文字描画データが大きくなる傾向にある。特に日本語フォントのような文字種の多いフォントを埋め込む場合にこの問題が顕著である。
【００３１】
次にフォントファイルの内部情報について、図１６を用いて説明する。フォントファイルには主に以下の情報が含まれる。
【００３２】
図１６は、情報処理装置におけるフォントファイルのデータ構造を説明する図である。
【００３３】
図１６において、フェース名は使用するフォントファイルを識別するための識別名である。
【００３４】
グリフ定義数は、フォントファイル内に定義されている「文字の形状を表すグリフ」の数を示し、本例では「１００」の場合を示す。グリフインデックステーブルは、1つのフォントファイルで様々な文字コードに対応するために、TrueTypeやOpenType等のフォントファイルでは、フォントファイル中の個々のグリフに対して文字コードに依存しないようにグリフを管理している。
【００３５】
一般にこのグリフの識別子をグリフインデックスと呼ぶ。それぞれの文字コード体系に対して、文字コードと対応するグリフインデックスとの対応表をグリフインデックステーブルと呼ぶ。
【００３６】
図１６に示す例では、２つのグリフインデックステーブル（UnicodeとShiftJIS）が示されている。一般的なグリフインデックステーブルでは、文字コードからグリフインデックスを特定できるデータ形式となっている。
【００３７】
グリフは、上述しているように文字の形状を表す情報である。グリフを表す方法としては、ビットマップ、パス、曲線等の形式がある。定義された各々のグリフは、フォント内ではフォント依存のグリフインデックスによって識別される。
【００３８】
グリフインデックスはフォント依存であるため、図１６に示すように、「A」のグリフインデックスが、「ゴシック」フォントでは0x0001、「明朝」フォントでは、0x0010と、通常同じ文字でもフォントファイルによってグリフインデックスは異なる。
【００３９】
また、図１６の「明朝フォント」における「£」（イギリスポンド）のように、フォントファイルによっては、グリフが定義されていない文字も存在する。そのような文字を印刷しようとした場合、図１４の右側に示すように、指定したフォントによって「・」や「□」等のグリフ不定義の文字を表す文字が描画される。
【００４０】
ところで、例えば内部文字コードとしてShiftJISしかサポートしていないＯＳの場合、イギリスポンドのグリフが定義されている「ゴシック」フォントであっても、ShiftJISでの文字コードの定義が存在せず、イギリスポンドが表示できない。
【００４１】
ＯＳの商業利用上のためには£（イギリスポンド）やユーロ記号のように一般的な文字が表示できないことは好ましくない。そのため、フォント依存のグリフインデックスを文字コードのかわりに使用し、文字描画のための情報を指定するＯＳやアプリケーションが存在する。その仕組みについて説明する。
【００４２】
図１３に戻って、アプリケーション１００１は、GDIを介し、Unicodeを用いて、ShiftJISでは表現できない文字描画をグラフィックエンジン１００２に対して命令する。グラフィックエンジン１００２は、ＯＳ内部でUnicodeを使用できないために、Unicodeで指定された文字のフォントに対応するグリフインデックステーブルを参照し、テーブル中に含まれるUnicodeに対応するグリフインデックスに変換する。
【００４３】
更にグラフィックエンジン１００２は、グリフインデックスを文字描画の文字コードとしてプリンタドライバ１００３に渡す。プリンタドライバ１００３は、グラフィックエンジン１００２に対してグリフインデックスを指定して文字グリフの取得を行う。グラフィックエンジン１００２は、指定されたグリフインデックスのグリフをフォントファイルより取得し、プリンタドライバ１００３へ受け渡す。プリンタドライバ１０００３は、受け取ったグリフを元に、文字描画コマンドを生成する。
【００４４】
この処理の流れはOSがグラフィックエンジン１００２にてグリフインデックス変換を行うものであるが、アプリケーション１００１が文字出力のGDIをコールする際に、Unicodeではなく、グリフインデックスを指定する事も可能である。その場合の処理は次のようになる。
【００４５】
アプリケーション１００１がフォントファイルを解析し、Unicodeに対応するグリフインデックスを取得し、GDIを介して文字描画を依頼してくる。グラフィックエンジン１００２は、グリフインデックスを文字描画の文字コードとしてプリンタドライバ１００３に渡す。
【００４６】
プリンタドライバ１００３は、グラフィックエンジン１００２に対してグリフインデックスを指定して文字グリフの取得を行う。グラフィックエンジン１００２は、指定されたグリフインデックスのグリフをフォントファイルより取得し、プリンタドライバ１００３へ受け渡す。
【００４７】
プリンタドライバ１００３は、受け取ったグリフを元に、文字描画コマンドを生成する。
【００４８】
ここで、グリフインデックス変換を行うのが、アプリケーション１００１であるかOSであるかにかかわらず、プリンタドライバ１００３に対して、文字描画命令にグリフインデックスが指定されてくる場合の印字方法をグリフインデックス印字と呼ぶ。
【００４９】
また、プリンタドライバ１００３に対して、文字描画命令にUnicodeが指定されてくる場合の印字方法をUnicode印字と呼ぶ。
【００５０】
従来の印刷制御装置においては、グリフインデックス印字時に次のような課題があった。
【００５１】
ここで、情報処理装置は、プリンタに送信する印刷データを生成する前に、中間フォーマットで一時保存を行うスプーラを備えているものとする。さらに、情報処理装置は、上記中間フォーマットデータから改めて最終的にプリンタに送付する印刷データを生成するデスプーラとプリンタ制御コマンドを生成するプリンタドライバを備えるものとする。このような情報処理装置においては、文字コードの代わりフォントに依存したグリフを識別するコード（グリフインデックス）が用いられた場合、デスプーラでフォント置き換えが発生した際に文字化けが発生するおそれがある。
【００５２】
また、プリンタ内蔵フォントで使用可能な文字コードへ変換できず、プリンタ内蔵フォントへの置き換え処理を適用できない。また、このような問題を解決するために、フォント置き換えではなく文字描画をビットマップ描画に置き換えて処理したとしても、デスプーラでの拡大時の文字品位が低下する場合があった。
【００５３】
さらに、色処理、圧縮処理が適用できない、プリンタ内蔵フォントへの置き換えが不可能である等の問題もあった。更に、ファイル出力系のプリンタドライバにおいて、生成した中間フォーマット内のテキスト情報を検索できないという場合もあった。
【００５４】
また、情報処理装置のディスク上に中間フォーマットファイルとして蓄積することを目的とした中間フォーマットの多くは、文字コードを保持するフォーマットを採用している。そうすることで、中間フォーマットファイルを扱うアプリケーションに、文字の検索等の機能を搭載する事ができるためである。
【００５５】
しかしながら、情報処理装置上のプリンタドライバを介して、アプリケーション文書から中間フォーマットファイルを生成する場合、グリフインデックス印字が為されてしまうと、文字コード情報が取得できずアプリケーションにおいて文字検索機能が使えないという場合があった。
【００５６】
このような問題点を解決するために、グリフインデック印字がなされた場合、グリフインデックスに対応する文字コードを取得し、その文字コードを用いて中間フォーマットファイルを生成する方法が提案されている（例えば、特許文献１参照）。
【００５７】
この方法によれば、グリフインデックスを文字コードに変換してからスプール、またはファイル出力することにより、アプリケーションが指定してきた文字コードの情報を失うことなく中間フォーマットファイルを生成できる。
【００５８】
その結果、その後フォント置き換えが発生した場合でも文字化けが起こらず、ユーザが意図した文字を印刷することが可能になるほか、一般的な文字コードを用いた描画の際の、色処理、圧縮、プリンタ内蔵フォント置き換えの処理を文字描画に適用可能になる。
【００５９】
また、ファイル出力の場合、文字コード情報を中間フォーマットファイル内に格納することが可能となり、アプリケーションにおける文字検索機能が使用できるようになる。
【００６０】
図１７〜図１９を用いて、従来の情報処理装置における文字処理について詳しく説明する。
【００６１】
図１７は、従来の情報処理装置におけるアプリケーション文書の一例を示す模式図である。
【００６２】
図１７において、元文書Ａは、図１６で示したゴシックフォントの「ABC渡辺」という文字を含む文書である。この文書をグリフインデックス印字にて中間フォーマットに変換すると、図１８、図１９で示すような中間フォーマットが生成される。図１８，図１９は前述のフォント埋め込み技術に該当する。
【００６３】
図１８は、情報処理装置で扱う中間フォーマットファイルの一つであるＰＤＦファイル内の構造を説明する模式図である。ただし、図１８はＰＤＦの仕様を正確に表したものではない。
【００６４】
図１８において、文字描画命令コマンド５０１で示す部分は、描画する文字のフォント種やフォントサイズ、描画位置、グリフインデックスを記述しており、ここで指定されたフォント種「F1」の情報はフォント情報部５０２に記述されている。
【００６５】
また、グリフインデックスで指定された文字の実体であるグリフはフォントグリフ部５０４に格納されている。また、アプリケーションにおける文字検索機能が使用できるようにするための文字コード情報として、グリフインデックスとUnicodeの関係を記述するToUnicode部５０３が含まれる。
【００６６】
アプリケーションはこのToUnicode部５０３に格納されている情報を元に文字検索機能を実現するのが一般的である。
【００６７】
従来技術では、グリフインデックス印字時、グリフインデックスに対応する文字コードを取得し、その文字コードをToUnicode部５０３に格納することによって、アプリケーションにおける文字検索機能を使用可能とするのである。
【００６８】
図１９は、図１８で示した中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示した図である。
【００６９】
図１９によれば、図１７で示した元文書Ａと同じ文字コードが格納されていることがわかる。
【特許文献１】特開2003-015850号公報
【発明の開示】
【発明が解決しようとする課題】
【００７０】
フォントファイルには、複数の文字コードで1つのグリフ（文字形状）を共通に使用するものが存在する。グリフインデックステーブルで言えば、複数の文字コードが同一のグリフインデックスを指しているフォントファイルがある、という事である。
【００７１】
このようなフォントファイルの場合、グリフインデックス印字が実行されると、従来技術では次のような課題がある。
【００７２】
すなわち、グリフインデックスから該当文字コードを取得しようとしても、候補が複数あるためプリンタドライバ側からでは、どの文字コードがアプリケーションの意図したものであるか判断できない。そのため、アプリケーション文書で検索可能であった文字が中間フォーマットファイルに変換した場合に検索不可能になる場合がある。
【００７３】
図１６の「明朝」フォントを例にとると、「辺」と「邊」は異なる文字コードであるが、同一のグリフインデックス「0x0003」を指している。アプリケーションが、「明朝」フォントの「辺」をグリフインデックス印字にて印刷を実行した際、プリンタドライバには、「明朝」フォント、グリフインデックス「0x0003」という情報が伝えられる。しかし、文字コード情報は送られてこない。
【００７４】
プリンタドライバからすると、「0x0003」に該当する文字コードが「辺」、「邊」の２つ存在する事になり、アプリケーションがどちらの文字コードにて印刷してきたか判断する事ができない。
【００７５】
この結果、生成した中間フォーマットファイルにおいて、該当文字はグリフが同じであるため見た目は問題ない。
【００７６】
しかし、実際に格納されている文字コード（ToUnicode部５０３に格納されている値）がアプリケーションの意図したものではなくなる場合があり、検索機能が正常に動作しないという課題がある。
【００７７】
図２０、図２１を用いてもう少し詳しく説明する。
【００７８】
図１７で示した元文書Ｂは、図１６で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表した図である。
【００７９】
このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換すると、従来技術では、図２０、図２１で示すような中間フォーマットが生成できる。
【００８０】
図２０、図２１は、図１８、図１９と同様にそれぞれ中間フォーマットファイルの一つであるＰＤＦファイル内の構造を説明する模式図である。本例は、中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものを示す例である。
【００８１】
図２０において、グリフインデックスとUnicodeの関係を記述するToUnicode部７０３のうち、グリフインデックス「0x0003」に「0x908A」が格納されている。「明朝」フォントの「辺」をグリフインデックス印字にて印刷を実行した際、プリンタドライバからすると、「0x003」に該当する文字コードが「辺（0x8FBA）」、「邊(0x908A)」の２つ存在する。
【００８２】
そのため、アプリケーションがどちらの文字コードにて印刷してきたか判断できないために起り得る現象である。
【００８３】
図２１によれば、図１７で示した元文書Bとは異なる文字コードが格納されていることがわかる。これにより元文書Ｂでは「辺（0x8FBA）」の文字コードで検索できたが、中間フォーマットファイル上では検索できなくなってしまうのである。これはToUnicode部７０３に格納されている文字コードが「邊(0x908A)」となっているためである。
【００８４】
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、複数の文字コードが１つのグリフ（文字形状）を共通に使用している文字でも，中間フォーマットファイル内にアプリケーションが元々保持していた文字コードを格納できる仕組みを提供することである。
【課題を解決するための手段】
【００８５】
上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。
【００８６】
アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置であって、前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する文字コードを取得する取得手段と、前記取得手段により取得する１つのグリフインデックスに対して複数の文字コードから選択される１つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当て手段と、前記割り当て手段により前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理手段とを有することを特徴とする。
【発明の効果】
【００８７】
複数の文字コードが１つのグリフ（文字形状）を共通に使用している文字でも，中間フォーマットファイル内にアプリケーションが元々保持していた文字コードを格納する事ができる。また、アプリケーションの検索処理を一切変更することなく，アプリケーションが元々保持していた文字コードで文字を検索する事が可能になる。
【発明を実施するための最良の形態】
【００８８】
次に本発明を実施するための最良の形態について図面を参照して説明する。
【００８９】
＜システム構成の説明＞
〔第１実施形態〕
図１Ａは、本実施形態を示す情報処理装置の構成を説明するブロック図である。本例は、一般的なコンピュータである情報処理装置１００の内部システムに対応する。以下、情報処理装置１００において、アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する処理を説明する。
【００９０】
図１Ａにおいて、ＣＰＵ１０１はＲＯＭ１０２あるいはＲＡＭ１０３あるいは外部記憶装置１０５に格納されたプログラムに従って装置全体の制御を行う。
【００９１】
ＲＡＭ１０３はＣＰＵ１０１が各種処理を行う際のワークエリアとして使用される。外部記憶装置１０５はオペレーティングシステム（ＯＳ）やアプリケーションソフト、プリンタドライバソフト等を記録する。
【００９２】
キーボード１０４もしくは図示していないマウスなどの入力機器は、ユーザが各種指示を与えるためのデバイスである。
【００９３】
ネットワークＩ／Ｆ１０６およびプリンタＩ／Ｆ１０７はイーサネット（登録商標）１１２または専用インターフェース１１１を介してプリンタと接続し、データの授受を行うためのインターフェースである。
【００９４】
モニタＩ／Ｆ１０８はモニタに接続し表示データの転送を行うためのインターフェースである。また、１１０は共通データバスである。
【００９５】
以下、図１Ｂを参照して情報処理装置における印刷処理を説明する。
【００９６】
図１Ｂは、図１Ａに示した情報処理装置における印刷システムのモジュール構成を説明するブロック図である。本例は、情報処理装置１００のＲＡＭ１０３にロードされたプログラムモジュールに対応する。
【００９７】
図１Ｂにおいて、アプリケーション１０５Ｂ、グラフィックエンジン１０５Ｄ、プリンタドライバ１０５Ｃは、外部記憶装置１０５に保存されたファイルとして存在する。そして、これらは、ＯＳ１０５Ａやそのモジュールを利用するモジュールによってＲＡＭ１０３にロードされて実行されるプログラムモジュールである。
【００９８】
また、アプリケーション１０５Ｂおよびプリンタドライバ１０５Ｃは、外部記憶装置１０５のＦＤや不図示のＣＤ−ＲＯＭ、あるいは不図示のネットワークを経由して外部記憶装置１０５のＨＤに追加することが可能となっている。
【００９９】
アプリケーション１０５Ｂからプリンタ１００４（図１３）に対して印刷を行う際には、グラフィックエンジン１０５Ｄを利用して出力（描画）を行う。ユーザはプリンタごとに用意されたプリンタドライバ１０５Ｃを、アプリケーション１０５Ｂの出力先として設定する。
【０１００】
ユーザはさらにアプリケーション１０５Ｂ上で、必要に応じてあらかじめ印刷出力に関わる印刷設定を行う。ユーザはアプリケーション１０５Ｂ、もしくはプリンタドライバの有するユーザインタフェースを通じて設定値を入力することができる。以降の処理の流れは既に説明しているため、ここでは省略する。
【０１０１】
なお、本実施形態ではプリンタドライバは、PDFやSVG等を作成するファイル出力系のプリンタドライバとして説明するが、本発明はプリンタ出力するためのPDLを作成するプリンタドライバにも適用できる。
【０１０２】
＜中間フォーマットファイル生成処＞
図２は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、中間フォーマットファイルを生成する処理例である。Ｓ８０１〜Ｓ８１０は各ステップを示し、各ステップは、ＣＰＵ１０１がＲＡＭ１０３上にアプリケーション、プリンタドライバをロードして実行することで実現される。
【０１０３】
本処理は、ユーザから印刷指示を受け付けたアプリケーション１０５Ｂは、グラフィックエンジン１０５Ｄを介してプリンタドライバ１０５Ｃに、印刷対象ファイルを中間フォーマットへ変換する要求を出すと開始される。
【０１０４】
まず、Ｓ８０１で、アプリケーション１０５Ｂは、変換ジョブが開始することを、ＧＤＩ関数を介してグラフィックエンジン１０５Ｄに通知する。グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。
【０１０５】
次に、Ｓ８０２で、プリンタドライバ１０５Ｃは、ジョブ開始コマンドを生成する。そして、Ｓ８０３で、アプリケーション１０５Ｂはページが開始することを、ＧＤＩ関数を介してグラフィックエンジン１０５Ｄに通知する。次に、Ｓ８０４で、グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。プリンタドライバ１０５Ｃは、ページ開始コマンドを生成する。
【０１０６】
そして、Ｓ８０５で、アプリケーション１０５Ｂは論理描画要求を、GDI関数を介してグラフィックエンジン１０５Ｄに通知する。グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。
【０１０７】
次に、Ｓ８０６で、プリンタドライバ１０５Ｃは、論理描画コマンドを生成する。Ｓ８０７で、アプリケーション１０５Ｂは、ページの終了要求が通知されるまで、Ｓ８０５、Ｓ８０６の処理を繰り返す。そして、ページ終了要求が通知されたら、アプリケーション１０５Ｂが、ページが終了することを、ＧＤＩ関数を介してグラフィックエンジン１０５Ｄに通知する。そして、Ｓ８０８で、グラフィックエンジン１０５Ｄが通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡すと、プリンタドライバ１０５Ｃは、ページ終了コマンドを生成する。
【０１０８】
そして、Ｓ８０９で、アプリケーション１０５Ｂからのジョブ終了要求が通知されるまで、Ｓ８０５〜Ｓ８０８を繰り返して、アプリケーション１０５Ｂが、ジョブが終了することを、ＧＤＩ関数を介してグラフィックエンジンに通知する。
【０１０９】
そして、Ｓ８１０で、グラフィックエンジン１０５Ｄが通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡すと、プリンタドライバ１０５Ｃは、ジョブ終了コマンドを生成して、本処理を終了する。
【０１１０】
＜文字描画の処理手順＞
図３は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、Ｓ８０５，Ｓ８０６に対応する文字描画処理例である。Ｓ９０１〜Ｓ９１５は各ステップを示し、各ステップは、ＣＰＵ１０１がＲＡＭ１０３上にアプリケーション、プリンタドライバをロードして実行することで実現される。
【０１１１】
なお、S９０１はアプリケーション１０５Ｂおよびグラフィックスエンジン１０５Ｄで行われるステップＳ８０５の一部であり、ステップＳ９０２〜Ｓ９１５はプリンタドライバ１０５Ｃで行われるステップＳ８０６の一部である。グラフィックスやイメージについても同様に描画処理が行われるが、図３ではそれらは省略している。
【０１１２】
まず、Ｓ９０１で、アプリケーション１０５Ｂは文字描画要求を出す際、ＧＤＩ関数を用いて文字コード、フォント属性、描画属性もしくは、グリフインデックス、フォント属性、描画属性をグラフィックエンジン１０５Ｄに通知する。そして、グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。
【０１１３】
次に、Ｓ９０２で、プリンタドライバ１０５Ｃは、ＧＤＩ関数のパラメータとして受け取ったフォント属性に含まれるフォントフェース名をもとにして、フォントファイルをシステム（ＯＳ）から読み込む。そして、Ｓ９０２で、プリンタドライバ１０５Ｃは、フォントファイル内に含まれるグリフインデックステーブルを取得する。
【０１１４】
次に、プリンタドライバ１０５Ｃは、Ｓ９０１にてアプリケーション１０５Ｂから送られてきた描画命令に文字コードが含まれていればUnicode印字と判断してＳ９０５へ移行する。逆に、グリフインテックスが含まれていればグリフインデックス印字と判断してＳ９０８へ移行する（Ｓ９０４）。
【０１１５】
そして、Ｓ９０５では、プリンタドライバ１０５Ｃは、Ｓ９０３にて取得したグリフインデックステーブルを利用して、Ｓ９０１で受け取った文字コードに該当するグリフインデックスを取得する。次に、Ｓ９０６で、プリンタドライバ１０５Ｃは、グリフインデックスから文字形状情報を示すグリフを取得する。
【０１１６】
そして、Ｓ９０７で、プリンタドライバ１０５Ｃは、Ｓ９０１で受け取った文字コード、フォント属性、描画属性、Ｓ９０５にて取得したグリフインデックス、Ｓ９０６にて取得したグリフを用いて、中間フォーマットに沿った文字描画コマンドを生成して、処理を終了する。
【０１１７】
Ｓ９０４にて、グリフインデックス印字と判断された場合、Ｓ９０８で、プリンタドライバ１０５Ｃは、Ｓ９０３にて取得したグリフインデックステーブルから図４に示すグリフインデックス逆引きテーブルを作成する。
【０１１８】
図４、図５は、図１に示したプリンタドライバ１０５Ｃが作成するグリフインデックス逆引きテーブルの一例を示す図である。なお、図４は、更新前のグリフインデックス逆引きテーブルに対応し、図５は更新後のグリフインデックス逆引きテーブルに対応する。
【０１１９】
図４に示す例は、図３で示したグリフインデックステーブルから作成したグリフインデックス逆引きテーブルを示すものである。
【０１２０】
先述の通り、一般的なグリフインデックステーブルは、文字コードからグリフインデックスを引くデータ形式となっているが、ここでは逆にグリフインデックスから文字コードを引く処理テーブルを作成する。
【０１２１】
次に、Ｓ９０９で、プリンタドライバ１０５Ｃは、Ｓ９０８で作成したグリフインデックス逆引きテーブルを利用して、Ｓ９０１で受け取ったグリフインデックスに該当する文字コードを取得する。
【０１２２】
この文字コードを取得する際、文字コード候補が複数ある場合、候補の中で一番大きい値の文字コード１つを取得する。これは、先述の通りフォントファイルには、複数の文字コードが１つのグリフを共通に使用するものが存在するためである。
【０１２３】
具体的には、図４に示す「明朝」フォントの例ではグリフインデックス0x0003のように、グリフインデックスに対して文字コードが複数割り当っている場合、文字コード0x908Aがこれに該当する。なお、実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に問わない。
【０１２４】
次に、Ｓ９１０で、プリンタドライバ１０５Ｃは、Ｓ９０１で受け取ったグリフインデックスから文字形状情報を示すグリフを取得する。次に、Ｓ９１１で、プリンタドライバ１０５Ｃは、Ｓ１０１で受け取ったグリフインデックス、フォント属性、描画属性、Ｓ９０９にて取得した文字コード、Ｓ９１０にて取得したグリフを用いて、中間フォーマットに沿った文字描画コマンドを生成する。
【０１２５】
次に、Ｓ９１２で、プリンタドライバ１０５Ｃは、Ｓ９０９にて文字コードを取得する際に、当該グリフインデックスに割り当てられた文字コード候補が複数あるかどうかを判断する。ここで、当該グリフインデックスに割り当てられた文字コード候補が複数あるとプリンタドライバ１０５Ｃが判断した場合は、Ｓ９１３へ移行し、一つしかないとプリンタドライバ１０５Ｃが判断した場合は、本処理を終了する。
【０１２６】
次に、Ｓ９１３で、プリンタドライバ１０５Ｃは、グリフインデックス逆引きテーブルを解析し、文字コードの割り当っていないグリフインデックス（空のグリフインデックス）を探索し、その値を保持する。
【０１２７】
図４に示す「明朝」フォントの例にすると、0x0070や0x0071や0x0072が文字コードの割り当っていないグリフインデックスに該当する。つまり、プリンタドライバ１０５Ｃは、取得する１つのグリフインデックスに対して複数の文字コードから選択される１つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる。これにより、アプリケーションが元々保持している文字コードで文字検索を行うことができる。
【０１２８】
次に、Ｓ９１４で、プリンタドライバ１０５Ｃは、Ｓ９１３で取得した未使用のグリフインデックスに、Ｓ９１１で出力した文字コード以外の文字コード候補の中で、一番大きい値の文字コードを割り当てる。
【０１２９】
図４に示す「明朝」フォントの例にすると、グリフインデックス0x070に対して、Unicode 0x8FBAを割り当て、「明朝」フォントのグリフインデックス逆引きテーブルを図５に示すように更新するのである。尚、本実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に方法は問わない。
【０１３０】
次に、Ｓ９１５で、プリンタドライバ１０５Ｃは、Ｓ９１３で取得したグリフインデックス、Ｓ９１４にて取得した文字コード、Ｓ９１０にて取得したグリフ、Ｓ９０１で受け取ったフォント属性、描画属性を用いて、中間フォーマットに沿った文字描画コマンドを生成する。尚、ここでは、Ｓ９０１から受け取った描画属性のうち色に関する情報を無視し、透明属性で文字描画コマンドを生成するものとする。また、Ｓ９１２〜Ｓ９１５の処理は、Ｓ９０９にて取得したすべての文字コード候補に対して処理を行うまで繰り返す。
【０１３１】
このような手順で作成できる中間フォーマットファイルについて、図６、図７を用いて説明する。
【０１３２】
なお、図１７で示した元文書Ｂは、図１６で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表していることは上述した通りである。このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換する際、図２、図３のフロー図で示した手順を踏むことよって、図６、図７で示すような中間フォーマットファイルが生成できる。
【０１３３】
図６は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。本例は、図６に示す中間フォーマットファイルの一つであるＰＤＦファイル内の構造を模式的に表したものである。
【０１３４】
図７は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの表示例を示す図である。本例は、中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものである。
【０１３５】
図６において、グリフインデックスとUnicodeの関係を記述するToUnicode部１３０３のうち、グリフインデックス「0x0003」に「0x908A」が、「0x0070」に「0x8FBA」がそれぞれ格納されている。また文字描画命令コマンド１３０１で示す部分には、描画する文字としてグリフインデックス「0x0003」の他に、透明属性の文字として「0x0070」が描画されている。
【０１３６】
また、図７によれば、図１６で示した元文書Bとは異なる文字コード「0x908A」の他に、「0x8FBA」が格納されていることがわかる。これにより中間フォーマットファイル上でも元文書Bで検索可能であった「0x8FBA」を検索できるようになるのである。
【０１３７】
〔第２実施形態〕
第２実施例においては、文字描画の処理手順（図３で説明した手順）が第１実施形態と異なる。第１実施形態では、一つのグリフインデックスに複数の文字コードが割当たっているようなフォントファイルにおけるグリフインデックス印字の際に、「文字単位」で文字を透明出力する描画コマンドを生成するものである。
【０１３８】
図７で示したように、「ＡＢＣ渡辺」という文字に対して、「0x0041, 0x0042, 0x0043, 0x6E21, 0x908A」と、「0x8FBA」，という文字コード情報を内部に保持している。
【０１３９】
この文字コード情報によりアプリケーションから「辺（0x8FBA）」の文字コードでの検索が可能になる。しかしながら、この方法では、アプリケーションから文字列検索を行う場合に、「渡邉（0x6E21, 0x908A）」での検索は可能であるが、「渡辺（0x6E21, 0x8FBA）」での検索ができない。
【０１４０】
そこで、第２実施形態では、文字列単位で透明出力する文字列描画コマンドの生成する方法を示す。その他の処理や構成については第１実施形態と同じであるため説明は省略する。以下、図２に示したＳ８０５，Ｓ８０６における論理描画処理の内、文字列描画コマンドについて図８に示すフローチャートを用いた処理について説明する。
【０１４１】
＜文字列描画の処理手順＞
図８は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は文字列描画処理例である。Ｓ１６０１〜Ｓ１６１８は各ステップを示し、各ステップは、ＣＰＵ１０１がＲＡＭ１０３上にアプリケーション、プリンタドライバをロードして実行することで実現される。図８において、Ｓ１６０１はアプリケーション１０５Ｂおよびグラフィックスエンジン１０５Ｄで行われるＳ８０５の一部である。また、Ｓ１６０２〜Ｓ１６１８はプリンタドライバ１０５Ｃで行われるＳ８０６の一部である。グラフィックスやイメージについても同様に描画処理が行われるが、図８ではそれらは省略している。
【０１４２】
Ｓ１６０１で、アプリケーション１０５ＢはＧＤＩ関数を介して、文字列描画要求を出す際、各文字の文字コード、フォント属性、描画属性もしくは、グリフインデックス、フォント属性、描画属性をグラフィックエンジン１０５Ｄに通知する。グラフィックエンジン１０５Ｄは通知されたＧＤＩ関数をＤＤＩ関数に変換してプリンタドライバ１０５Ｃへ引き渡す。
【０１４３】
次に、Ｓ１６０２で、プリンタドライバ１０５Ｃは、ＧＤＩ関数のパラメータとして受け取ったフォント属性に含まれるフォントフェース名をもとにして、フォントファイルをシステム（ＯＳ）から読み込む。そして、Ｓ１６０３で、プリンタドライバ１０５Ｃは、フォントファイル内に含まれるグリフインデックステーブルを取得する。
【０１４４】
次に、Ｓ１６０４で、プリンタドライバ１０５Ｃは、Ｓ１６０１にてアプリケーション１０５Ｂから送られてきた描画命令に文字コードが含まれていればUnicode印字と判断した場合は、Ｓ１６０５へ移行する。Ｓ１６０４で、逆に、グリフインテックスが含まれているとプリンタドライバ１０５Ｃが判断した場合は、グリフインデックス印字と判断してＳ１６０８へ移行する。
【０１４５】
Ｓ１６０５で、プリンタドライバ１０５Ｃは、Ｓ１６０３にて取得したグリフインデックステーブルを利用して、Ｓ１６０１で受け取った文字列それぞれの文字コードに該当するグリフインデックスを取得する。
【０１４６】
次に、Ｓ１６０６で、プリンタドライバ１０５Ｃは、各グリフインデックスから文字形状情報を示す各グリフを取得する。そして、Ｓ１６０７で、プリンタドライバ１０５Ｃは、文字列描画コマンドを生成して、処理を終了する。
【０１４７】
具体的には、Ｓ１６０１で受け取った文字列の文字コード、フォント属性、描画属性、Ｓ１６０５にて取得したグリフインデックス、Ｓ１６０６にて取得したグリフを用いて、中間フォーマットに沿った文字列描画コマンドを生成する。
【０１４８】
一方、Ｓ１６０４にて、グリフインデックス印字とプリンタドライバ１０５Ｃが判断した場合は、以下のＳ１６０８以降の処理を実行する。
【０１４９】
Ｓ１６０８で、プリンタドライバ１０５Ｃは、Ｓ１６０３にて取得したグリフインデックステーブルからグリフインデックス逆引きテーブルを作成する。なお、グリフインデックス逆引きテーブルの例は図４で説明したためここでの説明は省略する。
【０１５０】
次に、Ｓ１６０９で、プリンタドライバ１０５Ｃは、文字列のすべての文字に対して処理を実行したかどうかを判断する。ここで、文字列のすべての文字に対して処理を実行していないとプリンタドライバ１０５Ｃが判断した場合は、Ｓ１６１０へ進む。そして、Ｓ１６１０で、プリンタドライバ１０５Ｃは、Ｓ１６０８で作成したグリフインデックス逆引きテーブルを利用して、Ｓ１６０１で受け取ったグリフインデックスに該当する文字コードを取得する。この文字コードを取得する際、文字コード候補が複数ある場合、候補の中で一番大きい値の文字コード１つを取得する。具体的には、グリフインデックス逆引きテーブル内に、当該グリフインデックスに対して文字コードが複数割り当っている場合、図４の「明朝」フォントの例ではグリフインデックス0x0003がこれに該当する。
【０１５１】
なお、本実施例では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に問わない。
【０１５２】
次に、Ｓ１６１１で、プリンタドライバ１０５Ｃは、Ｓ１６０１で受け取ったグリフインデックスから文字形状情報を示すグリフを取得する。
【０１５３】
次に、Ｓ１６１２で、プリンタドライバ１０５Ｃは、Ｓ１６０１で受け取ったグリフインデックス、フォント属性、描画属性、Ｓ１６１０にて取得した文字コード、Ｓ１６１１にて取得したグリフの情報を文字列キャッシュテーブルに格納しておく。
【０１５４】
図９は、本実施形態を示す情報処理装置で管理される文字列キャッシュテーブルの一例を示す図である。ここでは、文字描画コマンドの生成に必要な情報である、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、の情報を文字列キャッシュテーブルに格納する。
【０１５５】
次に、Ｓ１６１３で、プリンタドライバ１０５Ｃは、Ｓ１６１０にて文字コードを取得する際に、当該グリフインデックに割り当てられた文字コード候補が複数あると判断した場合、Ｓ１６１４へ移行する。また、当該グリフインデックに割り当てられた文字コード候補が一つしかないとプリンタドライバ１０５Ｃが判断した場合は、Ｓ１６０９へ移行する。
【０１５６】
次に、Ｓ１６１４で、プリンタドライバ１０５Ｃは、グリフインデックス逆引きテーブルを解析し、文字コードの割り当っていないグリフインデックスを探索し、その値を保持する。図４に示す「明朝」フォントの例にすると、0x0070や0x0071が文字コードの割り当っていないグリフインデックスに該当する。
【０１５７】
次に、Ｓ１６１５で、プリンタドライバ１０５Ｃは、Ｓ１６１４で取得した未使用のグリフインデックスに、Ｓ９１１で出力した文字コード以外の文字コード候補の中で、一番大きい値の文字コードを割り当てる。また、プリンタドライバ１０５Ｃは、Ｓ１６１４、Ｓ１６１５で取得したグリフインデックスと、該当グリフインデックスに割り当てられたUnicodeを文字列キャッシュテーブルの透明出力グリフインデックス、透明出力文字コードにそれぞれ格納し保持させておく。
【０１５８】
図４に示す「明朝」フォントの例にすると、グリフインデックス0x070に対して、Unicode 0x8FBAを割り当て、「明朝」フォントのグリフインデックス逆引きテーブルを図５に示すように更新するのである。なお、本実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に方法は問わない。
【０１５９】
プリンタドライバ１０５Ｃは、文字列に含まれる文字すべてに対してＳ１６１０からＳ１６１６までの処理を行い、この時点で、図９に示した文字列キャッシュテーブルが完成したら、Ｓ１６０９からＳ１６１７へ進む。
【０１６０】
次に、Ｓ１６１７で、プリンタドライバ１０５Ｃは、Ｓ１６１６までの処理で生成した文字列キャッシュテーブルに格納されている、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、を元に中間フォーマットに沿った文字描画コマンドを生成する。
【０１６１】
次に、Ｓ１６１８で、プリンタドライバ１０５Ｃは、文字列キャッシュテーブル内に、透明出力グリフインデックス、透明出力文字コードが格納されている場合、透明出力グリフインデックス、透明出力文字コードが格納されていない文字と、格納されている文字を組み合わせて、文字列を生成する。さらに、プリンタドライバ１０５Ｃは、その文字列に含まれる文字の、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、の情報を元に中間フォーマットに沿った文字描画コマンドを透明属性にて生成して、本処理を終了する。ここで、透明属性とは、文字を透明状態で表示する属性であって、この属性を本実施形態において非表示属性と呼ぶ。
【０１６２】
このような手順で作成できる中間フォーマットファイルについて、図１０、図１１を用いて説明する。
【０１６３】
なお、図１７で示した元文書Ｂは、図１６で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表していることは上述した通りである。このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換する際、図２、図８に示すフロー図で示した手順を踏むことよって、図１０、図１１で示すような中間フォーマットが生成できる。
【０１６４】
図１０、図１１は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。ここで、図１０は中間フォーマットファイルの一つであるＰＤＦファイル内の構造を模式的に表したものである。また、図１１は中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものである。
【０１６５】
図１０において、グリフインデックスとUnicodeの関係を記述するToUnicode部１３０３のうち、グリフインデックス「0x0003」に「0x908A」が、「0x0070」に「0x8FBA」がそれぞれ格納されている。また文字描画命令コマンド１３０１で示すテキスト情報の部分には、描画する文字としてグリフインデックス「0x0003」の他に、透明属性の文字として「0x0070」が描画されている。
【０１６６】
また、図１１によれば、図１６で示した元文書Bとは異なる文字コード「0x908A」の他に、「0x8FBA」が格納されていることがわかる。これにより中間フォーマットファイル上でも元文書Bで検索可能であった「0x8FBA」を含む文字列を検索できるようになるのである。
【０１６７】
なお、第１及び第２実施形態ともに、日本語漢字領域の文字コードを例に説明してきたが、中国語や韓国語、欧米文字領域の文字コード等についても本件は適用可能である。
【０１６８】
ここでは欧文フォントを例に説明する。Unicodeでは、アルファベットや「!」や、「-」とった文字に対して、それぞれ全角文字が別に定義されている。
【０１６９】
例えば、欧米で一般的に使われる「Ａ」はUnicodeでは、「0x0041」であるが、全角用「Ａ」のUnicodeは「0xff21」である。また、同様に一般的な「-」は「0x002d」であるが、全角用の「‐」は「0xff0d」である。フォントによっては、上記のような文字コードにおいて、一般的に使わるコードと全角用のコードで同じグリフ（文字形状）を共通に使用するものが存在する。
【０１７０】
グリフインデックステーブルで言えば、例えば「0x0041」と「0xff21」の文字コードが同一のグリフインデックスを指しているフォントファイルがある、ということである。
【０１７１】
このようなフォントファイルにおいて、アプリケーション１０５Ｂから「0x0041」の文字をグリフインデックス印字で描画命令が実行された場合、プリンタドライバ１０５Ｃは、図３で示した手順（特にＳ９０８〜Ｓ９１５）もしくは、図８で示した手順（特にＳ１６０８〜Ｓ１６１８）を踏むことにより、中間フォーマットファイル内に「0xff21」の文字と、「0x0041」の透明文字を格納することが可能となる。これにより中間フォーマットファイル上でも元文書で検索可能であった「0x0041」を検索できるようになるのである。
【０１７２】
以下、図１２に示すメモリマップを参照して本発明に係る情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
【０１７３】
図１２は、本発明に係る情報処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【０１７４】
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１７５】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１７６】
本実施形態におけるフローチャートに示す機能が外部からインストールされるプログラムによって、情報処理装置により遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１７７】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１７８】
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【０１７９】
従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１８０】
プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。
【０１８１】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶したコンピュータ読み取り可能な記憶媒体は本発明を構成することになる。
【０１８２】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバやｆｔｐサーバ等も本発明の請求項に含まれるものである。
【０１８３】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１８４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。例えばそのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１８５】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１８６】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。
【０１８７】
本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。
【図面の簡単な説明】
【０１８８】
【図１Ａ】本実施形態を示す情報処理装置の構成を説明するブロック図である。
【図１Ｂ】図１Ａに示した情報処理装置における印刷システムのモジュール構成を説明するブロック図である。
【図２】本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。
【図３】本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。
【図４】図１に示したプリンタドライバ１０５Ｃが作成するグリフインデックス逆引きテーブルの一例を示す図である。
【図５】図１に示したプリンタドライバ１０５Ｃが作成するグリフインデックス逆引きテーブルの一例を示す図である。
【図６】本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。
【図７】本実施形態を示す情報処理装置で扱う中間フォーマットファイルの表示例を示す図である。
【図８】本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。
【図９】本実施形態を示す情報処理装置で管理される文字列キャッシュテーブルの一例を示す図である。
【図１０】本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。
【図１１】本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。
【図１２】本発明に係る情報処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
【図１３】従来の印刷システムに係る情報処理装置のモジュール構成を説明するブロック図である。
【図１４】情報処理装置における文字描画に必要な情報の例を表す模式図である。
【図１５】従来の情報処理装置における描画処理を説明する図である。
【図１６】情報処理装置におけるフォントファイルのデータ構造を説明する図である。
【図１７】従来の情報処理装置におけるアプリケーション文書の一例を示す模式図である。
【図１８】情報処理装置で扱う中間フォーマットファイルの一つであるＰＤＦファイル内の構造を説明する模式図である。
【図１９】図１８で示した中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示した図である。
【図２０】情報処理装置で扱う中間フォーマットファイルの一つであるＰＤＦファイル内の構造を説明する模式図である。
【図２１】図２０で示した中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示した図である。
【符号の説明】
【０１８９】
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０５ 外部記憶装置
１０５Ｂ アプリケーション
１０５Ｃ プリンタドライバ
【特許請求の範囲】
【請求項１】
アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、
前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する文字コードを取得する取得手段と、
前記取得手段により取得する１つのグリフインデックスに対して複数の文字コードから選択される１つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当て手段と、
前記割り当て手段により前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記処理手段は、中間フォーマット文書に格納する非表示属性の文字を、文字列単位で格納することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記非表示属性は、文字を透明状態で表示する属性であることを特徴とする請求項１又は２記載の情報処理装置。
【請求項４】
アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置におけるデータ処理方法であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断ステップと、
前記グリフインデックスが含まれると前記判断ステップが判断した場合、前記グリフインデックスに対応する文字コードを取得する取得ステップと、
前記取得ステップにより取得する１つのグリフインデックスに対して複数の文字コードから選択される１つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当てステップと、
前記割り当てステップにより前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理ステップと、
を有することを特徴とするデータ処理方法。
【請求項５】
前記処理ステップは、中間フォーマット文書に格納する非表示属性の文字を、文字列単位で格納することを特徴とする請求項４に記載のデータ処理方法。
【請求項６】
前記非表示属性は、文字を透明状態で表示する属性であることを特徴とする請求項４又は５記載のデータ処理方法。
【請求項７】
請求項４乃至６のいずれか１項に記載のデータ処理方法をコンピュータに実行させることを特徴とするプログラム。
【請求項８】
請求項４乃至６のいずれか１項に記載のデータ処理方法をコンピュータに実行させるためのプログラムを格納したことを特徴とするコンピュータが読み取り可能な記憶媒体。
【請求項９】
アプリケーションから受け取る印刷命令から中間フォーマット文書を生成する情報処理装置であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、
前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する複数の文字コードを取得する取得手段と、
前記取得手段により取得されたグリフインデックスに対する複数の文字コードのうちの１つの文字コードを含むテキスト情報と、残りの文字コードを含むテキスト情報とを含む中間フォーマット文書を生成する生成手段と、
を有することを特徴とする情報処理装置。
【請求項１】
アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、
前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する文字コードを取得する取得手段と、
前記取得手段により取得する１つのグリフインデックスに対して複数の文字コードから選択される１つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当て手段と、
前記割り当て手段により前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理手段と、
を有することを特徴とする情報処理装置。
【請求項２】
前記処理手段は、中間フォーマット文書に格納する非表示属性の文字を、文字列単位で格納することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記非表示属性は、文字を透明状態で表示する属性であることを特徴とする請求項１又は２記載の情報処理装置。
【請求項４】
アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置におけるデータ処理方法であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断ステップと、
前記グリフインデックスが含まれると前記判断ステップが判断した場合、前記グリフインデックスに対応する文字コードを取得する取得ステップと、
前記取得ステップにより取得する１つのグリフインデックスに対して複数の文字コードから選択される１つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当てステップと、
前記割り当てステップにより前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理ステップと、
を有することを特徴とするデータ処理方法。
【請求項５】
前記処理ステップは、中間フォーマット文書に格納する非表示属性の文字を、文字列単位で格納することを特徴とする請求項４に記載のデータ処理方法。
【請求項６】
前記非表示属性は、文字を透明状態で表示する属性であることを特徴とする請求項４又は５記載のデータ処理方法。
【請求項７】
請求項４乃至６のいずれか１項に記載のデータ処理方法をコンピュータに実行させることを特徴とするプログラム。
【請求項８】
請求項４乃至６のいずれか１項に記載のデータ処理方法をコンピュータに実行させるためのプログラムを格納したことを特徴とするコンピュータが読み取り可能な記憶媒体。
【請求項９】
アプリケーションから受け取る印刷命令から中間フォーマット文書を生成する情報処理装置であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、
前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する複数の文字コードを取得する取得手段と、
前記取得手段により取得されたグリフインデックスに対する複数の文字コードのうちの１つの文字コードを含むテキスト情報と、残りの文字コードを含むテキスト情報とを含む中間フォーマット文書を生成する生成手段と、
を有することを特徴とする情報処理装置。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１０−１２５８１０（Ｐ２０１０−１２５８１０Ａ）
【公開日】平成２２年６月１０日（２０１０．６．１０）
【国際特許分類】
【出願番号】特願２００８−３０５９３８（Ｐ２００８−３０５９３８）
【出願日】平成２０年１２月１日（２００８．１２．１）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２２年６月１０日（２０１０．６．１０）
【国際特許分類】
【出願日】平成２０年１２月１日（２００８．１２．１）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]