JP2010125810A - 情報処理装置、データ処理方法、プログラム及び記憶媒体 - Google Patents
情報処理装置、データ処理方法、プログラム及び記憶媒体 Download PDFInfo
- Publication number
- JP2010125810A JP2010125810A JP2008305938A JP2008305938A JP2010125810A JP 2010125810 A JP2010125810 A JP 2010125810A JP 2008305938 A JP2008305938 A JP 2008305938A JP 2008305938 A JP2008305938 A JP 2008305938A JP 2010125810 A JP2010125810 A JP 2010125810A
- Authority
- JP
- Japan
- Prior art keywords
- character
- glyph index
- glyph
- character code
- intermediate format
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Landscapes
- Record Information Processing For Printing (AREA)
Abstract
【課題】 複数の文字コードが1つのグリフ(文字形状)を共通に使用している文字でも,中間フォーマットファイル内にアプリケーションが元々保持していた文字コードを格納することである。
【解決手段】 アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する際に、印刷命令のうち文字描画命令にグリフインデックスを含む場合、グリフインデックスに対応する文字コードを取得する(S908,S909)。そして、1つのグリフインデックスに対して割り当てられている複数の文字コードを使用していないグリフインデックスに割り当てる(S913,S914)。さらに、使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する(S915)ことを特徴とする。
【選択図】 図3
【解決手段】 アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する際に、印刷命令のうち文字描画命令にグリフインデックスを含む場合、グリフインデックスに対応する文字コードを取得する(S908,S909)。そして、1つのグリフインデックスに対して割り当てられている複数の文字コードを使用していないグリフインデックスに割り当てる(S913,S914)。さらに、使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する(S915)ことを特徴とする。
【選択図】 図3
Description
本発明は、アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置のデータ処理に関するものである。
図13は、従来の印刷システムに係る情報処理装置のモジュール構成を説明するブロック図である。本例は、ホストコンピュータ1000とプリンタ1004とが直接あるいはネットワーク経由で接続されている印刷システムに対応する。
図13において、印刷処理は、ホストコンピュータ1000のユーザが、ワードプロセッサプログラムや表計算プログラム等のアプリケーション1001から、印刷指示を行うことによって開始する。
アプリケーション1001は、文字描画データ等を含むアプリケーションデータを解析して、例えばOS(基本ソフト)が提供するグラフィックエンジン1002をコールする。
グラフィックエンジン1002は、例えば、Windows(登録商標)(米国マイクロソフト社の登録商標)では、GDI(Graphic Device Interface)と呼ばれておりディスプレイやプリンタに対する画像情報の処理を司っている。
グラフィックエンジン1002は、プリンタ1004の種類に合わせて用意されたプリンタドライバ1003をロードし、アプリケーション1001の出力をプリンタドライバ1003に受け渡す。
そして、アプリケーション1001から受け取るGDI(Graphic Device Interface)関数からDDI(Device Driver Interface)関数に変換して、プリンタドライバ1003へDDI関数を出力する。
プリンタドライバ1003は、グラフィックエンジン1002から受け取ったDDI関数に基づいて、プリンタが認識可能なプリンタ制御コマンド、例えばPDL(Page Description Language)等の中間フォーマットに変換する。そして、プリンタドライバ1003は変換されたプリンタ制御コマンドをプリンタ1004へ印刷データとして出力する。
プリンタ1004ではこの制御コマンドを解釈して、ビットマップデータへ展開し、最終的に紙などの記録媒体に印刷結果が出力される。
また、プリンタドライバ1003には、上述のようにプリンタ1004で出力するものの他に、ファイル出力するものもある(以下、ファイル出力系プリンタドライバと呼ぶ)。ここで、ファイル出力とは、プリンタ1004にデータを送ることが直接的な目的ではなく、DDI関数から受け取った描画命令を予め定義された中間フォーマットに変換し、ホストコンピュータ1000のディスク上に中間フォーマットファイルとして蓄積するのである。
この代表的な中間フォーマットにはPDF(Portable Document Format)やSVG(Scalable Vector Graphics)等が存在する。中間フォーマットファイルはホストコンピュータ1000上のファイルシステム上に保存され、解釈可能な特定のアプリケーションによりホストコンピュータ1000が備える表示装置上で表示できる。また、ユーザの指示により再びグラフィックエンジン1002を介してプリンタ1004で印刷を行うことが可能である。
次に、Windows(登録商標)システムにおける文字描画を行う際の処理について説明する。
図14は、情報処理装置における文字描画に必要な情報の例を表す模式図である。
図14は一例であるが、一般的に文字描画コマンドには以下の4つのフォント情報が必要である。
第1のフォント情報は文字コードである。ここで、文字コードは、
文字描画で伝えたいところの文字情報であって、例えばASCII、ShiftJIS、Unicode等、あらかじめ定められたコード体系に従ったコードが用いられる。
文字描画で伝えたいところの文字情報であって、例えばASCII、ShiftJIS、Unicode等、あらかじめ定められたコード体系に従ったコードが用いられる。
第2のフォント情報はフォント属性である。ここで、フォント属性とは、文字描画に対応するフェース名、グリフへの修飾を表すイタリック/ボールド指定有無、文字の大きさを表すポイント数等の情報である。
第3のフォント情報は描画属性である。ここで、描画属性とは、文字の描画位置や、色、クリップの状態等を表す情報である。
第4のフォント情報は、フォントファイルである。ここで、フォントファイルとは、ゴシックや明朝等のフェース名で指定される文字描画形状を表す情報である。また、第4のフォント情報には、内部に文字コード毎の描画形状情報(以下、グリフと呼ぶ)を有する。
フォントファイルの情報方式としては、大きくビットマップフォントとアウトラインフォントに分かれ、TrueType、OpenType等の各種フォーマットが定義されている。フォントファイルの内部情報については、さらに後述する。
そして、これらの情報全てが揃わなければ、ユーザが意図した通りの文字描画は成立しない。しかし、文字描画形状を表す情報であるフォントファイルは、例えば著作権の関係等によって、すべての環境に必要とするフォントファイルが存在する保証はない。
言い換えると、ユーザが文字描画データを作成した環境に存在したフォントファイルが、文字描画が行われる環境で存在しない可能性がある。描画が行われる環境にユーザが意図したフォントファイルが存在しない場合にも、ユーザが意図したフォントファイル、もしくはそれに近い形状のフォントファイルで文字描画を行うために、従来、以下の3つの仕組みが知れている。
第1はフォント置き換え、第2はビットマップ置き換え及び、第3はフォント埋め込みという仕組みである。
以下、それぞれの仕組みを用いた場合の描画結果を示す図15を参照して、それぞれの仕組みについて説明する。
図15は、従来の情報処理装置における描画処理を説明する図である。
〔フォント置き換え〕
文字描画実行環境において、フォントの置き換えは、文字描画データ中のフォント属性に近い別のフォントを用いて描画を行う方法である。ここで、別のフォントを指定する方法としては、文字描画を行うアプリケーションが予め定義した変換テーブルを用いる方法、OSやプリンタ等が予め定義した変換テーブルを用いる方法が一般的である。
文字描画実行環境において、フォントの置き換えは、文字描画データ中のフォント属性に近い別のフォントを用いて描画を行う方法である。ここで、別のフォントを指定する方法としては、文字描画を行うアプリケーションが予め定義した変換テーブルを用いる方法、OSやプリンタ等が予め定義した変換テーブルを用いる方法が一般的である。
フォント置き換えは、文字描画データを作成する際に、文字描画コマンド(文字コード、フォント属性、描画属性)を作成するが、最もデータ量の多いフォントファイルは必要ないため文字描画データは小さいという利点がある。一方、フォント置き換えによると、別のフォントファイルを用いるため図15の右最上段に示すように、ユーザが意図していたものとは違った形状の文字描画が行われる可能性がある。
このため上記処理によれば、意図した文字コードに対応したフォントファイルが文字描画実行環境において存在せず、文字として識別不可能な描画が行われることもある。
例えば、一般的に欧米で用いられているOS上には、日本語フォントファイルは存在しない。そのため、文字描画データを作成した環境が一般的な日本のOS上であり、文字描画を行う環境が一般的な欧米のOS上であった場合、文字コードに対応したフォントファイルが存在せず、結果として識別不可能な描画が行われてしまう。
〔ビットマップ置き換え〕
ビットマップ置き換えは、文字描画データを作成する時点で文字描画をビットマップに変換して、文字描画をビットマップ描画に変換する方法である。通常の見た目はユーザが意図した文字描画と同じになる。しかしビットマップであるために図15右中段に示すように拡大/縮小時にビットマップの解像度の影響で文字品位が落ちる場合がある。
ビットマップ置き換えは、文字描画データを作成する時点で文字描画をビットマップに変換して、文字描画をビットマップ描画に変換する方法である。通常の見た目はユーザが意図した文字描画と同じになる。しかしビットマップであるために図15右中段に示すように拡大/縮小時にビットマップの解像度の影響で文字品位が落ちる場合がある。
〔フォント埋め込み〕
フォント埋め込みは、文字描画データ内に、文字描画コマンド(文字コード、フォント属性、描画属性)以外に、フォントファイルを埋め込ませ、文字描画が実際に行われる環境まで持っていく方法である。埋め込まれたフォントファイルは、文字描画データ内に含まれるため、文字描画を行う環境において、ユーザが意図した形式で文字描画される。フォント埋め込みは文字描画データ内の文字描画コマンドで指定されたフォントがOS上になくても、ユーザが意図した出力を得られるという利点がある。しかし、フォントファイルを文字描画データに内に埋め込むため、文字描画データが大きくなる傾向にある。特に日本語フォントのような文字種の多いフォントを埋め込む場合にこの問題が顕著である。
フォント埋め込みは、文字描画データ内に、文字描画コマンド(文字コード、フォント属性、描画属性)以外に、フォントファイルを埋め込ませ、文字描画が実際に行われる環境まで持っていく方法である。埋め込まれたフォントファイルは、文字描画データ内に含まれるため、文字描画を行う環境において、ユーザが意図した形式で文字描画される。フォント埋め込みは文字描画データ内の文字描画コマンドで指定されたフォントがOS上になくても、ユーザが意図した出力を得られるという利点がある。しかし、フォントファイルを文字描画データに内に埋め込むため、文字描画データが大きくなる傾向にある。特に日本語フォントのような文字種の多いフォントを埋め込む場合にこの問題が顕著である。
次にフォントファイルの内部情報について、図16を用いて説明する。フォントファイルには主に以下の情報が含まれる。
図16は、情報処理装置におけるフォントファイルのデータ構造を説明する図である。
図16において、フェース名は使用するフォントファイルを識別するための識別名である。
グリフ定義数は、フォントファイル内に定義されている「文字の形状を表すグリフ」の数を示し、本例では「100」の場合を示す。グリフインデックステーブルは、1つのフォントファイルで様々な文字コードに対応するために、TrueTypeやOpenType等のフォントファイルでは、フォントファイル中の個々のグリフに対して文字コードに依存しないようにグリフを管理している。
一般にこのグリフの識別子をグリフインデックスと呼ぶ。それぞれの文字コード体系に対して、文字コードと対応するグリフインデックスとの対応表をグリフインデックステーブルと呼ぶ。
図16に示す例では、2つのグリフインデックステーブル(UnicodeとShiftJIS)が示されている。一般的なグリフインデックステーブルでは、文字コードからグリフインデックスを特定できるデータ形式となっている。
グリフは、上述しているように文字の形状を表す情報である。グリフを表す方法としては、ビットマップ、パス、曲線等の形式がある。定義された各々のグリフは、フォント内ではフォント依存のグリフインデックスによって識別される。
グリフインデックスはフォント依存であるため、図16に示すように、「A」のグリフインデックスが、「ゴシック」フォントでは0x0001、「明朝」フォントでは、0x0010と、通常同じ文字でもフォントファイルによってグリフインデックスは異なる。
また、図16の「明朝フォント」における「£」(イギリスポンド)のように、フォントファイルによっては、グリフが定義されていない文字も存在する。そのような文字を印刷しようとした場合、図14の右側に示すように、指定したフォントによって「・」や「□」等のグリフ不定義の文字を表す文字が描画される。
ところで、例えば内部文字コードとしてShiftJISしかサポートしていないOSの場合、イギリスポンドのグリフが定義されている「ゴシック」フォントであっても、ShiftJISでの文字コードの定義が存在せず、イギリスポンドが表示できない。
OSの商業利用上のためには£(イギリスポンド)やユーロ記号のように一般的な文字が表示できないことは好ましくない。そのため、フォント依存のグリフインデックスを文字コードのかわりに使用し、文字描画のための情報を指定するOSやアプリケーションが存在する。その仕組みについて説明する。
図13に戻って、アプリケーション1001は、GDIを介し、Unicodeを用いて、ShiftJISでは表現できない文字描画をグラフィックエンジン1002に対して命令する。グラフィックエンジン1002は、OS内部でUnicodeを使用できないために、Unicodeで指定された文字のフォントに対応するグリフインデックステーブルを参照し、テーブル中に含まれるUnicodeに対応するグリフインデックスに変換する。
更にグラフィックエンジン1002は、グリフインデックスを文字描画の文字コードとしてプリンタドライバ1003に渡す。プリンタドライバ1003は、グラフィックエンジン1002に対してグリフインデックスを指定して文字グリフの取得を行う。グラフィックエンジン1002は、指定されたグリフインデックスのグリフをフォントファイルより取得し、プリンタドライバ1003へ受け渡す。プリンタドライバ10003は、受け取ったグリフを元に、文字描画コマンドを生成する。
この処理の流れはOSがグラフィックエンジン1002にてグリフインデックス変換を行うものであるが、アプリケーション1001が文字出力のGDIをコールする際に、Unicodeではなく、グリフインデックスを指定する事も可能である。その場合の処理は次のようになる。
アプリケーション1001がフォントファイルを解析し、Unicodeに対応するグリフインデックスを取得し、GDIを介して文字描画を依頼してくる。グラフィックエンジン1002は、グリフインデックスを文字描画の文字コードとしてプリンタドライバ1003に渡す。
プリンタドライバ1003は、グラフィックエンジン1002に対してグリフインデックスを指定して文字グリフの取得を行う。グラフィックエンジン1002は、指定されたグリフインデックスのグリフをフォントファイルより取得し、プリンタドライバ1003へ受け渡す。
プリンタドライバ1003は、受け取ったグリフを元に、文字描画コマンドを生成する。
ここで、グリフインデックス変換を行うのが、アプリケーション1001であるかOSであるかにかかわらず、プリンタドライバ1003に対して、文字描画命令にグリフインデックスが指定されてくる場合の印字方法をグリフインデックス印字と呼ぶ。
また、プリンタドライバ1003に対して、文字描画命令にUnicodeが指定されてくる場合の印字方法をUnicode印字と呼ぶ。
従来の印刷制御装置においては、グリフインデックス印字時に次のような課題があった。
ここで、情報処理装置は、プリンタに送信する印刷データを生成する前に、中間フォーマットで一時保存を行うスプーラを備えているものとする。さらに、情報処理装置は、上記中間フォーマットデータから改めて最終的にプリンタに送付する印刷データを生成するデスプーラとプリンタ制御コマンドを生成するプリンタドライバを備えるものとする。このような情報処理装置においては、文字コードの代わりフォントに依存したグリフを識別するコード(グリフインデックス)が用いられた場合、デスプーラでフォント置き換えが発生した際に文字化けが発生するおそれがある。
また、プリンタ内蔵フォントで使用可能な文字コードへ変換できず、プリンタ内蔵フォントへの置き換え処理を適用できない。また、このような問題を解決するために、フォント置き換えではなく文字描画をビットマップ描画に置き換えて処理したとしても、デスプーラでの拡大時の文字品位が低下する場合があった。
さらに、色処理、圧縮処理が適用できない、プリンタ内蔵フォントへの置き換えが不可能である等の問題もあった。更に、ファイル出力系のプリンタドライバにおいて、生成した中間フォーマット内のテキスト情報を検索できないという場合もあった。
また、情報処理装置のディスク上に中間フォーマットファイルとして蓄積することを目的とした中間フォーマットの多くは、文字コードを保持するフォーマットを採用している。そうすることで、中間フォーマットファイルを扱うアプリケーションに、文字の検索等の機能を搭載する事ができるためである。
しかしながら、情報処理装置上のプリンタドライバを介して、アプリケーション文書から中間フォーマットファイルを生成する場合、グリフインデックス印字が為されてしまうと、文字コード情報が取得できずアプリケーションにおいて文字検索機能が使えないという場合があった。
このような問題点を解決するために、グリフインデック印字がなされた場合、グリフインデックスに対応する文字コードを取得し、その文字コードを用いて中間フォーマットファイルを生成する方法が提案されている(例えば、特許文献1参照)。
この方法によれば、グリフインデックスを文字コードに変換してからスプール、またはファイル出力することにより、アプリケーションが指定してきた文字コードの情報を失うことなく中間フォーマットファイルを生成できる。
その結果、その後フォント置き換えが発生した場合でも文字化けが起こらず、ユーザが意図した文字を印刷することが可能になるほか、一般的な文字コードを用いた描画の際の、色処理、圧縮、プリンタ内蔵フォント置き換えの処理を文字描画に適用可能になる。
また、ファイル出力の場合、文字コード情報を中間フォーマットファイル内に格納することが可能となり、アプリケーションにおける文字検索機能が使用できるようになる。
図17〜図19を用いて、従来の情報処理装置における文字処理について詳しく説明する。
図17は、従来の情報処理装置におけるアプリケーション文書の一例を示す模式図である。
図17において、元文書Aは、図16で示したゴシックフォントの「ABC渡辺」という文字を含む文書である。この文書をグリフインデックス印字にて中間フォーマットに変換すると、図18、図19で示すような中間フォーマットが生成される。図18,図19は前述のフォント埋め込み技術に該当する。
図18は、情報処理装置で扱う中間フォーマットファイルの一つであるPDFファイル内の構造を説明する模式図である。ただし、図18はPDFの仕様を正確に表したものではない。
図18において、文字描画命令コマンド501で示す部分は、描画する文字のフォント種やフォントサイズ、描画位置、グリフインデックスを記述しており、ここで指定されたフォント種「F1」の情報はフォント情報部502に記述されている。
また、グリフインデックスで指定された文字の実体であるグリフはフォントグリフ部504に格納されている。また、アプリケーションにおける文字検索機能が使用できるようにするための文字コード情報として、グリフインデックスとUnicodeの関係を記述するToUnicode部503が含まれる。
アプリケーションはこのToUnicode部503に格納されている情報を元に文字検索機能を実現するのが一般的である。
従来技術では、グリフインデックス印字時、グリフインデックスに対応する文字コードを取得し、その文字コードをToUnicode部503に格納することによって、アプリケーションにおける文字検索機能を使用可能とするのである。
図19は、図18で示した中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示した図である。
図19によれば、図17で示した元文書Aと同じ文字コードが格納されていることがわかる。
特開2003-015850号公報
フォントファイルには、複数の文字コードで1つのグリフ(文字形状)を共通に使用するものが存在する。グリフインデックステーブルで言えば、複数の文字コードが同一のグリフインデックスを指しているフォントファイルがある、という事である。
このようなフォントファイルの場合、グリフインデックス印字が実行されると、従来技術では次のような課題がある。
すなわち、グリフインデックスから該当文字コードを取得しようとしても、候補が複数あるためプリンタドライバ側からでは、どの文字コードがアプリケーションの意図したものであるか判断できない。そのため、アプリケーション文書で検索可能であった文字が中間フォーマットファイルに変換した場合に検索不可能になる場合がある。
図16の「明朝」フォントを例にとると、「辺」と「邊」は異なる文字コードであるが、同一のグリフインデックス「0x0003」を指している。アプリケーションが、「明朝」フォントの「辺」をグリフインデックス印字にて印刷を実行した際、プリンタドライバには、「明朝」フォント、グリフインデックス「0x0003」という情報が伝えられる。しかし、文字コード情報は送られてこない。
プリンタドライバからすると、「0x0003」に該当する文字コードが「辺」、「邊」の2つ存在する事になり、アプリケーションがどちらの文字コードにて印刷してきたか判断する事ができない。
この結果、生成した中間フォーマットファイルにおいて、該当文字はグリフが同じであるため見た目は問題ない。
しかし、実際に格納されている文字コード(ToUnicode部503に格納されている値)がアプリケーションの意図したものではなくなる場合があり、検索機能が正常に動作しないという課題がある。
図20、図21を用いてもう少し詳しく説明する。
図17で示した元文書Bは、図16で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表した図である。
このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換すると、従来技術では、図20、図21で示すような中間フォーマットが生成できる。
図20、図21は、図18、図19と同様にそれぞれ中間フォーマットファイルの一つであるPDFファイル内の構造を説明する模式図である。本例は、中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものを示す例である。
図20において、グリフインデックスとUnicodeの関係を記述するToUnicode部703のうち、グリフインデックス「0x0003」に「0x908A」が格納されている。「明朝」フォントの「辺」をグリフインデックス印字にて印刷を実行した際、プリンタドライバからすると、「0x003」に該当する文字コードが「辺(0x8FBA)」、「邊(0x908A)」の2つ存在する。
そのため、アプリケーションがどちらの文字コードにて印刷してきたか判断できないために起り得る現象である。
図21によれば、図17で示した元文書Bとは異なる文字コードが格納されていることがわかる。これにより元文書Bでは「辺(0x8FBA)」の文字コードで検索できたが、中間フォーマットファイル上では検索できなくなってしまうのである。これはToUnicode部703に格納されている文字コードが「邊(0x908A)」となっているためである。
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、複数の文字コードが1つのグリフ(文字形状)を共通に使用している文字でも,中間フォーマットファイル内にアプリケーションが元々保持していた文字コードを格納できる仕組みを提供することである。
上記目的を達成する本発明の情報処理装置は以下に示す構成を備える。
アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置であって、前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する文字コードを取得する取得手段と、前記取得手段により取得する1つのグリフインデックスに対して複数の文字コードから選択される1つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当て手段と、前記割り当て手段により前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理手段とを有することを特徴とする。
複数の文字コードが1つのグリフ(文字形状)を共通に使用している文字でも,中間フォーマットファイル内にアプリケーションが元々保持していた文字コードを格納する事ができる。また、アプリケーションの検索処理を一切変更することなく,アプリケーションが元々保持していた文字コードで文字を検索する事が可能になる。
次に本発明を実施するための最良の形態について図面を参照して説明する。
<システム構成の説明>
〔第1実施形態〕
図1Aは、本実施形態を示す情報処理装置の構成を説明するブロック図である。本例は、一般的なコンピュータである情報処理装置100の内部システムに対応する。以下、情報処理装置100において、アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する処理を説明する。
〔第1実施形態〕
図1Aは、本実施形態を示す情報処理装置の構成を説明するブロック図である。本例は、一般的なコンピュータである情報処理装置100の内部システムに対応する。以下、情報処理装置100において、アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する処理を説明する。
図1Aにおいて、CPU101はROM102あるいはRAM103あるいは外部記憶装置105に格納されたプログラムに従って装置全体の制御を行う。
RAM103はCPU101が各種処理を行う際のワークエリアとして使用される。外部記憶装置105はオペレーティングシステム(OS)やアプリケーションソフト、プリンタドライバソフト等を記録する。
キーボード104もしくは図示していないマウスなどの入力機器は、ユーザが各種指示を与えるためのデバイスである。
ネットワークI/F106およびプリンタI/F107はイーサネット(登録商標)112または専用インターフェース111を介してプリンタと接続し、データの授受を行うためのインターフェースである。
モニタI/F108はモニタに接続し表示データの転送を行うためのインターフェースである。また、110は共通データバスである。
以下、図1Bを参照して情報処理装置における印刷処理を説明する。
図1Bは、図1Aに示した情報処理装置における印刷システムのモジュール構成を説明するブロック図である。本例は、情報処理装置100のRAM103にロードされたプログラムモジュールに対応する。
図1Bにおいて、アプリケーション105B、グラフィックエンジン105D、プリンタドライバ105Cは、外部記憶装置105に保存されたファイルとして存在する。そして、これらは、OS105Aやそのモジュールを利用するモジュールによってRAM103にロードされて実行されるプログラムモジュールである。
また、アプリケーション105Bおよびプリンタドライバ105Cは、外部記憶装置105のFDや不図示のCD−ROM、あるいは不図示のネットワークを経由して外部記憶装置105のHDに追加することが可能となっている。
アプリケーション105Bからプリンタ1004(図13)に対して印刷を行う際には、グラフィックエンジン105Dを利用して出力(描画)を行う。ユーザはプリンタごとに用意されたプリンタドライバ105Cを、アプリケーション105Bの出力先として設定する。
ユーザはさらにアプリケーション105B上で、必要に応じてあらかじめ印刷出力に関わる印刷設定を行う。ユーザはアプリケーション105B、もしくはプリンタドライバの有するユーザインタフェースを通じて設定値を入力することができる。以降の処理の流れは既に説明しているため、ここでは省略する。
なお、本実施形態ではプリンタドライバは、PDFやSVG等を作成するファイル出力系のプリンタドライバとして説明するが、本発明はプリンタ出力するためのPDLを作成するプリンタドライバにも適用できる。
<中間フォーマットファイル生成処>
図2は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、中間フォーマットファイルを生成する処理例である。S801〜S810は各ステップを示し、各ステップは、CPU101がRAM103上にアプリケーション、プリンタドライバをロードして実行することで実現される。
図2は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、中間フォーマットファイルを生成する処理例である。S801〜S810は各ステップを示し、各ステップは、CPU101がRAM103上にアプリケーション、プリンタドライバをロードして実行することで実現される。
本処理は、ユーザから印刷指示を受け付けたアプリケーション105Bは、グラフィックエンジン105Dを介してプリンタドライバ105Cに、印刷対象ファイルを中間フォーマットへ変換する要求を出すと開始される。
まず、S801で、アプリケーション105Bは、変換ジョブが開始することを、GDI関数を介してグラフィックエンジン105Dに通知する。グラフィックエンジン105Dは通知されたGDI関数をDDI関数に変換してプリンタドライバ105Cへ引き渡す。
次に、S802で、プリンタドライバ105Cは、ジョブ開始コマンドを生成する。そして、S803で、アプリケーション105Bはページが開始することを、GDI関数を介してグラフィックエンジン105Dに通知する。次に、S804で、グラフィックエンジン105Dは通知されたGDI関数をDDI関数に変換してプリンタドライバ105Cへ引き渡す。プリンタドライバ105Cは、ページ開始コマンドを生成する。
そして、S805で、アプリケーション105Bは論理描画要求を、GDI関数を介してグラフィックエンジン105Dに通知する。グラフィックエンジン105Dは通知されたGDI関数をDDI関数に変換してプリンタドライバ105Cへ引き渡す。
次に、S806で、プリンタドライバ105Cは、論理描画コマンドを生成する。S807で、アプリケーション105Bは、ページの終了要求が通知されるまで、S805、S806の処理を繰り返す。そして、ページ終了要求が通知されたら、アプリケーション105Bが、ページが終了することを、GDI関数を介してグラフィックエンジン105Dに通知する。そして、S808で、グラフィックエンジン105Dが通知されたGDI関数をDDI関数に変換してプリンタドライバ105Cへ引き渡すと、プリンタドライバ105Cは、ページ終了コマンドを生成する。
そして、S809で、アプリケーション105Bからのジョブ終了要求が通知されるまで、S805〜S808を繰り返して、アプリケーション105Bが、ジョブが終了することを、GDI関数を介してグラフィックエンジンに通知する。
そして、S810で、グラフィックエンジン105Dが通知されたGDI関数をDDI関数に変換してプリンタドライバ105Cへ引き渡すと、プリンタドライバ105Cは、ジョブ終了コマンドを生成して、本処理を終了する。
<文字描画の処理手順>
図3は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、S805,S806に対応する文字描画処理例である。S901〜S915は各ステップを示し、各ステップは、CPU101がRAM103上にアプリケーション、プリンタドライバをロードして実行することで実現される。
図3は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は、S805,S806に対応する文字描画処理例である。S901〜S915は各ステップを示し、各ステップは、CPU101がRAM103上にアプリケーション、プリンタドライバをロードして実行することで実現される。
なお、S901はアプリケーション105Bおよびグラフィックスエンジン105Dで行われるステップS805の一部であり、ステップS902〜S915はプリンタドライバ105Cで行われるステップS806の一部である。グラフィックスやイメージについても同様に描画処理が行われるが、図3ではそれらは省略している。
まず、S901で、アプリケーション105Bは文字描画要求を出す際、GDI関数を用いて文字コード、フォント属性、描画属性もしくは、グリフインデックス、フォント属性、描画属性をグラフィックエンジン105Dに通知する。そして、グラフィックエンジン105Dは通知されたGDI関数をDDI関数に変換してプリンタドライバ105Cへ引き渡す。
次に、S902で、プリンタドライバ105Cは、GDI関数のパラメータとして受け取ったフォント属性に含まれるフォントフェース名をもとにして、フォントファイルをシステム(OS)から読み込む。そして、S902で、プリンタドライバ105Cは、フォントファイル内に含まれるグリフインデックステーブルを取得する。
次に、プリンタドライバ105Cは、S901にてアプリケーション105Bから送られてきた描画命令に文字コードが含まれていればUnicode印字と判断してS905へ移行する。逆に、グリフインテックスが含まれていればグリフインデックス印字と判断してS908へ移行する(S904)。
そして、S905では、プリンタドライバ105Cは、S903にて取得したグリフインデックステーブルを利用して、S901で受け取った文字コードに該当するグリフインデックスを取得する。次に、S906で、プリンタドライバ105Cは、グリフインデックスから文字形状情報を示すグリフを取得する。
そして、S907で、プリンタドライバ105Cは、S901で受け取った文字コード、フォント属性、描画属性、S905にて取得したグリフインデックス、S906にて取得したグリフを用いて、中間フォーマットに沿った文字描画コマンドを生成して、処理を終了する。
S904にて、グリフインデックス印字と判断された場合、S908で、プリンタドライバ105Cは、S903にて取得したグリフインデックステーブルから図4に示すグリフインデックス逆引きテーブルを作成する。
図4、図5は、図1に示したプリンタドライバ105Cが作成するグリフインデックス逆引きテーブルの一例を示す図である。なお、図4は、更新前のグリフインデックス逆引きテーブルに対応し、図5は更新後のグリフインデックス逆引きテーブルに対応する。
図4に示す例は、図3で示したグリフインデックステーブルから作成したグリフインデックス逆引きテーブルを示すものである。
先述の通り、一般的なグリフインデックステーブルは、文字コードからグリフインデックスを引くデータ形式となっているが、ここでは逆にグリフインデックスから文字コードを引く処理テーブルを作成する。
次に、S909で、プリンタドライバ105Cは、S908で作成したグリフインデックス逆引きテーブルを利用して、S901で受け取ったグリフインデックスに該当する文字コードを取得する。
この文字コードを取得する際、文字コード候補が複数ある場合、候補の中で一番大きい値の文字コード1つを取得する。これは、先述の通りフォントファイルには、複数の文字コードが1つのグリフを共通に使用するものが存在するためである。
具体的には、図4に示す「明朝」フォントの例ではグリフインデックス0x0003のように、グリフインデックスに対して文字コードが複数割り当っている場合、文字コード0x908Aがこれに該当する。なお、実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に問わない。
次に、S910で、プリンタドライバ105Cは、S901で受け取ったグリフインデックスから文字形状情報を示すグリフを取得する。次に、S911で、プリンタドライバ105Cは、S101で受け取ったグリフインデックス、フォント属性、描画属性、S909にて取得した文字コード、S910にて取得したグリフを用いて、中間フォーマットに沿った文字描画コマンドを生成する。
次に、S912で、プリンタドライバ105Cは、S909にて文字コードを取得する際に、当該グリフインデックスに割り当てられた文字コード候補が複数あるかどうかを判断する。ここで、当該グリフインデックスに割り当てられた文字コード候補が複数あるとプリンタドライバ105Cが判断した場合は、S913へ移行し、一つしかないとプリンタドライバ105Cが判断した場合は、本処理を終了する。
次に、S913で、プリンタドライバ105Cは、グリフインデックス逆引きテーブルを解析し、文字コードの割り当っていないグリフインデックス(空のグリフインデックス)を探索し、その値を保持する。
図4に示す「明朝」フォントの例にすると、0x0070や0x0071や0x0072が文字コードの割り当っていないグリフインデックスに該当する。つまり、プリンタドライバ105Cは、取得する1つのグリフインデックスに対して複数の文字コードから選択される1つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる。これにより、アプリケーションが元々保持している文字コードで文字検索を行うことができる。
次に、S914で、プリンタドライバ105Cは、S913で取得した未使用のグリフインデックスに、S911で出力した文字コード以外の文字コード候補の中で、一番大きい値の文字コードを割り当てる。
図4に示す「明朝」フォントの例にすると、グリフインデックス0x070に対して、Unicode 0x8FBAを割り当て、「明朝」フォントのグリフインデックス逆引きテーブルを図5に示すように更新するのである。尚、本実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に方法は問わない。
次に、S915で、プリンタドライバ105Cは、S913で取得したグリフインデックス、S914にて取得した文字コード、S910にて取得したグリフ、S901で受け取ったフォント属性、描画属性を用いて、中間フォーマットに沿った文字描画コマンドを生成する。尚、ここでは、S901から受け取った描画属性のうち色に関する情報を無視し、透明属性で文字描画コマンドを生成するものとする。また、S912〜S915の処理は、S909にて取得したすべての文字コード候補に対して処理を行うまで繰り返す。
このような手順で作成できる中間フォーマットファイルについて、図6、図7を用いて説明する。
なお、図17で示した元文書Bは、図16で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表していることは上述した通りである。このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換する際、図2、図3のフロー図で示した手順を踏むことよって、図6、図7で示すような中間フォーマットファイルが生成できる。
図6は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。本例は、図6に示す中間フォーマットファイルの一つであるPDFファイル内の構造を模式的に表したものである。
図7は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの表示例を示す図である。本例は、中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものである。
図6において、グリフインデックスとUnicodeの関係を記述するToUnicode部1303のうち、グリフインデックス「0x0003」に「0x908A」が、「0x0070」に「0x8FBA」がそれぞれ格納されている。また文字描画命令コマンド1301で示す部分には、描画する文字としてグリフインデックス「0x0003」の他に、透明属性の文字として「0x0070」が描画されている。
また、図7によれば、図16で示した元文書Bとは異なる文字コード「0x908A」の他に、「0x8FBA」が格納されていることがわかる。これにより中間フォーマットファイル上でも元文書Bで検索可能であった「0x8FBA」を検索できるようになるのである。
〔第2実施形態〕
第2実施例においては、文字描画の処理手順(図3で説明した手順)が第1実施形態と異なる。第1実施形態では、一つのグリフインデックスに複数の文字コードが割当たっているようなフォントファイルにおけるグリフインデックス印字の際に、「文字単位」で文字を透明出力する描画コマンドを生成するものである。
第2実施例においては、文字描画の処理手順(図3で説明した手順)が第1実施形態と異なる。第1実施形態では、一つのグリフインデックスに複数の文字コードが割当たっているようなフォントファイルにおけるグリフインデックス印字の際に、「文字単位」で文字を透明出力する描画コマンドを生成するものである。
図7で示したように、「ABC渡辺」という文字に対して、「0x0041, 0x0042, 0x0043, 0x6E21, 0x908A」と、「0x8FBA」,という文字コード情報を内部に保持している。
この文字コード情報によりアプリケーションから「辺(0x8FBA)」の文字コードでの検索が可能になる。しかしながら、この方法では、アプリケーションから文字列検索を行う場合に、「渡邉(0x6E21, 0x908A)」での検索は可能であるが、「渡辺(0x6E21, 0x8FBA)」での検索ができない。
そこで、第2実施形態では、文字列単位で透明出力する文字列描画コマンドの生成する方法を示す。その他の処理や構成については第1実施形態と同じであるため説明は省略する。以下、図2に示したS805,S806における論理描画処理の内、文字列描画コマンドについて図8に示すフローチャートを用いた処理について説明する。
<文字列描画の処理手順>
図8は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は文字列描画処理例である。S1601〜S1618は各ステップを示し、各ステップは、CPU101がRAM103上にアプリケーション、プリンタドライバをロードして実行することで実現される。図8において、S1601はアプリケーション105Bおよびグラフィックスエンジン105Dで行われるS805の一部である。また、S1602〜S1618はプリンタドライバ105Cで行われるS806の一部である。グラフィックスやイメージについても同様に描画処理が行われるが、図8ではそれらは省略している。
図8は、本実施形態を示す情報処理装置におけるデータ処理手順の一例を示すフローチャートである。本例は文字列描画処理例である。S1601〜S1618は各ステップを示し、各ステップは、CPU101がRAM103上にアプリケーション、プリンタドライバをロードして実行することで実現される。図8において、S1601はアプリケーション105Bおよびグラフィックスエンジン105Dで行われるS805の一部である。また、S1602〜S1618はプリンタドライバ105Cで行われるS806の一部である。グラフィックスやイメージについても同様に描画処理が行われるが、図8ではそれらは省略している。
S1601で、アプリケーション105BはGDI関数を介して、文字列描画要求を出す際、各文字の文字コード、フォント属性、描画属性もしくは、グリフインデックス、フォント属性、描画属性をグラフィックエンジン105Dに通知する。グラフィックエンジン105Dは通知されたGDI関数をDDI関数に変換してプリンタドライバ105Cへ引き渡す。
次に、S1602で、プリンタドライバ105Cは、GDI関数のパラメータとして受け取ったフォント属性に含まれるフォントフェース名をもとにして、フォントファイルをシステム(OS)から読み込む。そして、S1603で、プリンタドライバ105Cは、フォントファイル内に含まれるグリフインデックステーブルを取得する。
次に、S1604で、プリンタドライバ105Cは、S1601にてアプリケーション105Bから送られてきた描画命令に文字コードが含まれていればUnicode印字と判断した場合は、S1605へ移行する。S1604で、逆に、グリフインテックスが含まれているとプリンタドライバ105Cが判断した場合は、グリフインデックス印字と判断してS1608へ移行する。
S1605で、プリンタドライバ105Cは、S1603にて取得したグリフインデックステーブルを利用して、S1601で受け取った文字列それぞれの文字コードに該当するグリフインデックスを取得する。
次に、S1606で、プリンタドライバ105Cは、各グリフインデックスから文字形状情報を示す各グリフを取得する。そして、S1607で、プリンタドライバ105Cは、文字列描画コマンドを生成して、処理を終了する。
具体的には、S1601で受け取った文字列の文字コード、フォント属性、描画属性、S1605にて取得したグリフインデックス、S1606にて取得したグリフを用いて、中間フォーマットに沿った文字列描画コマンドを生成する。
一方、S1604にて、グリフインデックス印字とプリンタドライバ105Cが判断した場合は、以下のS1608以降の処理を実行する。
S1608で、プリンタドライバ105Cは、S1603にて取得したグリフインデックステーブルからグリフインデックス逆引きテーブルを作成する。なお、グリフインデックス逆引きテーブルの例は図4で説明したためここでの説明は省略する。
次に、S1609で、プリンタドライバ105Cは、文字列のすべての文字に対して処理を実行したかどうかを判断する。ここで、文字列のすべての文字に対して処理を実行していないとプリンタドライバ105Cが判断した場合は、S1610へ進む。そして、S1610で、プリンタドライバ105Cは、S1608で作成したグリフインデックス逆引きテーブルを利用して、S1601で受け取ったグリフインデックスに該当する文字コードを取得する。この文字コードを取得する際、文字コード候補が複数ある場合、候補の中で一番大きい値の文字コード1つを取得する。具体的には、グリフインデックス逆引きテーブル内に、当該グリフインデックスに対して文字コードが複数割り当っている場合、図4の「明朝」フォントの例ではグリフインデックス0x0003がこれに該当する。
なお、本実施例では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に問わない。
次に、S1611で、プリンタドライバ105Cは、S1601で受け取ったグリフインデックスから文字形状情報を示すグリフを取得する。
次に、S1612で、プリンタドライバ105Cは、S1601で受け取ったグリフインデックス、フォント属性、描画属性、S1610にて取得した文字コード、S1611にて取得したグリフの情報を文字列キャッシュテーブルに格納しておく。
図9は、本実施形態を示す情報処理装置で管理される文字列キャッシュテーブルの一例を示す図である。ここでは、文字描画コマンドの生成に必要な情報である、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、の情報を文字列キャッシュテーブルに格納する。
次に、S1613で、プリンタドライバ105Cは、S1610にて文字コードを取得する際に、当該グリフインデックに割り当てられた文字コード候補が複数あると判断した場合、S1614へ移行する。また、当該グリフインデックに割り当てられた文字コード候補が一つしかないとプリンタドライバ105Cが判断した場合は、S1609へ移行する。
次に、S1614で、プリンタドライバ105Cは、グリフインデックス逆引きテーブルを解析し、文字コードの割り当っていないグリフインデックスを探索し、その値を保持する。図4に示す「明朝」フォントの例にすると、0x0070や0x0071が文字コードの割り当っていないグリフインデックスに該当する。
次に、S1615で、プリンタドライバ105Cは、S1614で取得した未使用のグリフインデックスに、S911で出力した文字コード以外の文字コード候補の中で、一番大きい値の文字コードを割り当てる。また、プリンタドライバ105Cは、S1614、S1615で取得したグリフインデックスと、該当グリフインデックスに割り当てられたUnicodeを文字列キャッシュテーブルの透明出力グリフインデックス、透明出力文字コードにそれぞれ格納し保持させておく。
図4に示す「明朝」フォントの例にすると、グリフインデックス0x070に対して、Unicode 0x8FBAを割り当て、「明朝」フォントのグリフインデックス逆引きテーブルを図5に示すように更新するのである。なお、本実施形態では、一番大きい値の文字コードを選ぶこととするが、複数候補からどの文字コードを選ぶかについては、特に方法は問わない。
プリンタドライバ105Cは、文字列に含まれる文字すべてに対してS1610からS1616までの処理を行い、この時点で、図9に示した文字列キャッシュテーブルが完成したら、S1609からS1617へ進む。
次に、S1617で、プリンタドライバ105Cは、S1616までの処理で生成した文字列キャッシュテーブルに格納されている、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、を元に中間フォーマットに沿った文字描画コマンドを生成する。
次に、S1618で、プリンタドライバ105Cは、文字列キャッシュテーブル内に、透明出力グリフインデックス、透明出力文字コードが格納されている場合、透明出力グリフインデックス、透明出力文字コードが格納されていない文字と、格納されている文字を組み合わせて、文字列を生成する。さらに、プリンタドライバ105Cは、その文字列に含まれる文字の、グリフインデックス、文字コード、フォント属性、描画属性、グリフ、の情報を元に中間フォーマットに沿った文字描画コマンドを透明属性にて生成して、本処理を終了する。ここで、透明属性とは、文字を透明状態で表示する属性であって、この属性を本実施形態において非表示属性と呼ぶ。
このような手順で作成できる中間フォーマットファイルについて、図10、図11を用いて説明する。
なお、図17で示した元文書Bは、図16で示した明朝フォントで「ABC渡辺」という文字を含むアプリケーション文書を模式的に表していることは上述した通りである。このアプリケーション文書をグリフインデックス印字にて中間フォーマットに変換する際、図2、図8に示すフロー図で示した手順を踏むことよって、図10、図11で示すような中間フォーマットが生成できる。
図10、図11は、本実施形態を示す情報処理装置で扱う中間フォーマットファイルの一例を示す図である。ここで、図10は中間フォーマットファイルの一つであるPDFファイル内の構造を模式的に表したものである。また、図11は中間フォーマットファイルを解釈可能な特定のアプリケーションにより情報処理装置上に表示させたものである。
図10において、グリフインデックスとUnicodeの関係を記述するToUnicode部1303のうち、グリフインデックス「0x0003」に「0x908A」が、「0x0070」に「0x8FBA」がそれぞれ格納されている。また文字描画命令コマンド1301で示すテキスト情報の部分には、描画する文字としてグリフインデックス「0x0003」の他に、透明属性の文字として「0x0070」が描画されている。
また、図11によれば、図16で示した元文書Bとは異なる文字コード「0x908A」の他に、「0x8FBA」が格納されていることがわかる。これにより中間フォーマットファイル上でも元文書Bで検索可能であった「0x8FBA」を含む文字列を検索できるようになるのである。
なお、第1及び第2実施形態ともに、日本語漢字領域の文字コードを例に説明してきたが、中国語や韓国語、欧米文字領域の文字コード等についても本件は適用可能である。
ここでは欧文フォントを例に説明する。Unicodeでは、アルファベットや「!」や、「-」とった文字に対して、それぞれ全角文字が別に定義されている。
例えば、欧米で一般的に使われる「A」はUnicodeでは、「0x0041」であるが、全角用「A」のUnicodeは「0xff21」である。また、同様に一般的な「-」は「0x002d」であるが、全角用の「‐」は「0xff0d」である。フォントによっては、上記のような文字コードにおいて、一般的に使わるコードと全角用のコードで同じグリフ(文字形状)を共通に使用するものが存在する。
グリフインデックステーブルで言えば、例えば「0x0041」と「0xff21」の文字コードが同一のグリフインデックスを指しているフォントファイルがある、ということである。
このようなフォントファイルにおいて、アプリケーション105Bから「0x0041」の文字をグリフインデックス印字で描画命令が実行された場合、プリンタドライバ105Cは、図3で示した手順(特にS908〜S915)もしくは、図8で示した手順(特にS1608〜S1618)を踏むことにより、中間フォーマットファイル内に「0xff21」の文字と、「0x0041」の透明文字を格納することが可能となる。これにより中間フォーマットファイル上でも元文書で検索可能であった「0x0041」を検索できるようになるのである。
以下、図12に示すメモリマップを参照して本発明に係る情報処理装置で読み取り可能なデータ処理プログラムの構成について説明する。
図12は、本発明に係る情報処理装置で読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。
なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報,作成者等も記憶され、かつ、プログラム読み出し側のOS等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
本実施形態におけるフローチャートに示す機能が外部からインストールされるプログラムによって、情報処理装置により遂行されていてもよい。そして、その場合、CD−ROMやフラッシュメモリやFD等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、OSに供給するスクリプトデータ等、プログラムの形態を問わない。
プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、MO、CD−ROM、CD−R、CD−RW、磁気テープ、不揮発性のメモリカード、ROM、DVDなどを用いることができる。
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶したコンピュータ読み取り可能な記憶媒体は本発明を構成することになる。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるWWWサーバやftpサーバ等も本発明の請求項に含まれるものである。
また、本発明のプログラムを暗号化してCD−ROM等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。例えばそのプログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形(各実施形態の有機的な組合せを含む)が可能であり、それらを本発明の範囲から除外するものではない。
本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。
101 CPU
102 ROM
103 RAM
105 外部記憶装置
105B アプリケーション
105C プリンタドライバ
102 ROM
103 RAM
105 外部記憶装置
105B アプリケーション
105C プリンタドライバ
Claims (9)
- アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、
前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する文字コードを取得する取得手段と、
前記取得手段により取得する1つのグリフインデックスに対して複数の文字コードから選択される1つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当て手段と、
前記割り当て手段により前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理手段と、
を有することを特徴とする情報処理装置。 - 前記処理手段は、中間フォーマット文書に格納する非表示属性の文字を、文字列単位で格納することを特徴とする請求項1に記載の情報処理装置。
- 前記非表示属性は、文字を透明状態で表示する属性であることを特徴とする請求項1又は2記載の情報処理装置。
- アプリケーションから受け取る印刷命令を中間フォーマット文書に変換する情報処理装置におけるデータ処理方法であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断ステップと、
前記グリフインデックスが含まれると前記判断ステップが判断した場合、前記グリフインデックスに対応する文字コードを取得する取得ステップと、
前記取得ステップにより取得する1つのグリフインデックスに対して複数の文字コードから選択される1つの文字コードを割り当て、残る文字コードを使用していないグリフインデックスに割り当てる割り当てステップと、
前記割り当てステップにより前記使用していないグリフインデックスに割り当てた文字コードの属性を非表示属性として前記中間フォーマット文書に格納する処理ステップと、
を有することを特徴とするデータ処理方法。 - 前記処理ステップは、中間フォーマット文書に格納する非表示属性の文字を、文字列単位で格納することを特徴とする請求項4に記載のデータ処理方法。
- 前記非表示属性は、文字を透明状態で表示する属性であることを特徴とする請求項4又は5記載のデータ処理方法。
- 請求項4乃至6のいずれか1項に記載のデータ処理方法をコンピュータに実行させることを特徴とするプログラム。
- 請求項4乃至6のいずれか1項に記載のデータ処理方法をコンピュータに実行させるためのプログラムを格納したことを特徴とするコンピュータが読み取り可能な記憶媒体。
- アプリケーションから受け取る印刷命令から中間フォーマット文書を生成する情報処理装置であって、
前記印刷命令のうち文字描画命令にグリフインデックスを含むかどうか判断する判断手段と、
前記グリフインデックスが含まれると前記判断手段が判断した場合、前記グリフインデックスに対応する複数の文字コードを取得する取得手段と、
前記取得手段により取得されたグリフインデックスに対する複数の文字コードのうちの1つの文字コードを含むテキスト情報と、残りの文字コードを含むテキスト情報とを含む中間フォーマット文書を生成する生成手段と、
を有することを特徴とする情報処理装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008305938A JP2010125810A (ja) | 2008-12-01 | 2008-12-01 | 情報処理装置、データ処理方法、プログラム及び記憶媒体 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008305938A JP2010125810A (ja) | 2008-12-01 | 2008-12-01 | 情報処理装置、データ処理方法、プログラム及び記憶媒体 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2010125810A true JP2010125810A (ja) | 2010-06-10 |
Family
ID=42326506
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008305938A Withdrawn JP2010125810A (ja) | 2008-12-01 | 2008-12-01 | 情報処理装置、データ処理方法、プログラム及び記憶媒体 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2010125810A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012063926A (ja) * | 2010-09-15 | 2012-03-29 | Alpine Electronics Inc | 名称検索方法および名称検索装置 |
JP2015016452A (ja) * | 2013-07-12 | 2015-01-29 | 住友化学株式会社 | 薄膜形成方法、及び、有機電子デバイスの製造方法 |
-
2008
- 2008-12-01 JP JP2008305938A patent/JP2010125810A/ja not_active Withdrawn
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012063926A (ja) * | 2010-09-15 | 2012-03-29 | Alpine Electronics Inc | 名称検索方法および名称検索装置 |
JP2015016452A (ja) * | 2013-07-12 | 2015-01-29 | 住友化学株式会社 | 薄膜形成方法、及び、有機電子デバイスの製造方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7570374B2 (en) | Document generation apparatus and file conversion system | |
JP4667280B2 (ja) | 情報処理装置及びその制御方法、プログラム | |
JP4785579B2 (ja) | 情報処理装置および情報処理装置における印刷設定反映方法とプログラム | |
JP4799206B2 (ja) | 印刷制御用プログラムおよび印刷制御装置及び印刷制御方法 | |
KR100661173B1 (ko) | 다이렉트 프린팅 기능을 갖는 프린터 및 그 인쇄방법 | |
JP6157210B2 (ja) | 文書変換装置、文書変換方法、及びプログラム | |
JP2009271930A (ja) | プリンタ定義ファイルを用いてjdfを生成するための方法、システムおよびプログラム | |
JP2008242661A (ja) | 印刷制御装置及び方法 | |
JP2004102618A (ja) | 印刷制御装置及び方法、コンピュータプログラム、コンピュータ読み取り可能な記憶媒体、プレビュー装置及び方法、プリンタドライバ及びそのプレビュー方法 | |
JP3209102B2 (ja) | プリントシステム、プリンタドライバ及びプリンタ | |
JP2009245433A (ja) | ページ記述言語を処理するシステム、方法及びコンピュータ可読媒体 | |
JP2003058528A (ja) | 文字処理装置および文字処理方法およびプログラム | |
JPH1069477A (ja) | 文字処理方法及び文字処理装置 | |
US20050094172A1 (en) | Linking font resources in a printing system | |
JP2010125810A (ja) | 情報処理装置、データ処理方法、プログラム及び記憶媒体 | |
CN107015770B (zh) | 信息处理设备和打印数据生成方法 | |
JP2005157686A (ja) | 印刷制御装置、印刷制御方法およびコンピュータプログラム | |
JP2010033360A (ja) | 情報処理装置、ジョブ処理方法、記憶媒体及びプログラム | |
JP6437076B2 (ja) | 情報処理装置及びその制御方法とプログラム | |
JP2006178622A (ja) | 文書変換方法、文書変換装置、及びプログラム | |
US8756491B2 (en) | PDL data processing device | |
JP2009289121A (ja) | 情報処理装置、出力装置、出力処理方法、及びプログラム | |
JP2004303077A (ja) | 情報処理装置及びページ記述言語生成方法、プログラム及び記憶媒体 | |
JP2009134645A (ja) | データ処理装置、印刷処理方法、記憶媒体、プログラム | |
JP7271208B2 (ja) | プログラム、および情報処理装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Withdrawal of application because of no request for examination |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20120207 |