JP2020144807A

JP2020144807A - 情報処理装置とその制御方法、及びプログラム

Info

Publication number: JP2020144807A
Application number: JP2019043049A
Authority: JP
Inventors: 仁長坂; Hitoshi Nagasaka
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2019-03-08
Filing date: 2019-03-08
Publication date: 2020-09-10

Abstract

【課題】フォント情報の属性を含むテキストの印刷時に、印刷装置に依らず、同じ品質の文字を印刷できる情報処理装置とその制御方法、及びプログラムを提供する。【解決手段】印刷装置に印刷ジョブを送信して印刷させる情報処理装置であって、入力されたテキスト描画命令において、フォント情報の属性に基づくシミュレーションが必要か否かを判定し、シミュレーションが必要であると判定された場合に、テキスト描画命令に基づくシミュレーションを実行してシミュレーションの結果を生成する。シミュレーションが必要でないと判定された場合はテキスト描画命令に基づいて制御コマンドを作成する。生成手段により生成されたシミュレーションの結果に基づく制御コマンド、或いは作成手段により作成された制御コマンドを印刷装置に送信する。【選択図】図７

Description

本発明は、情報処理装置とその制御方法、及びプログラムに関するものである。

プリンタドライバを用いて印刷を行う際、プリンタドライバは、ページ記述言語（ＰＤＬ）に定義される制御コマンド（以下、ＰＤＬコマンド）を用いて描画の種類や大きさ、色、位置などを表現し、プリンタに印刷を指示する。このＰＤＬには多くの種類が存在し、それぞれのＰＤＬで規定されているＰＤＬコマンドの種類や、表現可能な描画が異なる。具体的には、ＰＣＬ（登録商標）などがあり、特にＰＣＬは世界中で広く利用されているＰＤＬの１つである。

ＰＤＬコマンドの１つに、テキスト描画コマンドがある。これはその名の通り、テキストを描画するＰＤＬコマンドであるが、大きく分けて２種類の形式が存在する。図１を参照して具体的に説明する。

図１（Ａ）はビットマップダウンロードと呼ばれる方式であり、プリンタドライバによりフォントファイル等からテキストの情報を抽出し、ビットマップ化までを行う。そしてテキストをビットマップにした状態でＰＤＬコマンド化するものである。

図１（Ｂ）はフォントダウンロードと呼ばれる方式であり、プリンタドライバによりフォントファイル等からテキストの情報を抽出するまでを行う。そしてテキストをフォント情報のままＰＤＬコマンド化するものである。この場合、ビットマップ化を行うのはプリンタである。

図１（Ａ）のビットマップダウンロードに比べ、図１（Ｂ）のフォントダウンロードは一般にＰＤＬコマンドのファイルサイズが小さく、プリンタでの拡大が必要なケースでは描画品質がより保たれる。しかし、テキストの大きさがある程度小さい場合、逆にビットマップダウンロードのほうがファイルサイズが小さくなる。

ビットマップ化した場合、データサイズはテキストが描画される面積の大きさ（即ち、描画後の画素数）に依存するが、一定の面積内に描画されるテキストの複雑度には影響を受けない。一方、テキスト情報をビットマップ化したときのデータサイズは、テキストの大きさには影響を受けないが、描画する文字の複雑度等に依存する。従って、ビットマップダウンロードとフォントダウンロードのいずれを選択するとファイルサイズが小さくなるかは、描画内容によって異なる。

特許文献１には、印刷時の拡縮設定、印刷の品位モード、テキストのサイズを考慮してビットマップダウンロードか、フォントダウンロードかを自動選択する方法が記載されている。

特開２０００−２２５７５６号公報

フォント情報にはボールド（太字）やイタリック（斜体）を代表例とするスタイルと呼ばれる属性がある。そしてそのスタイルは、フォント情報のデータ、つまりフォントファイルに含まれるものもあれば、フォントファイルには含まれず、自前でスタイルを適用しなければならない場合もある。

図２を参照して、イタリックを例としてその流れを簡単に説明する。

図２（Ａ）は、イタリックの字体をフォントファイル２０１に持つ場合の例を示す。この場合、フォントファイル２０１をフォントエンジン等を用いて字体情報を取り出すと、イタリック字体のテキスト２０２が取得できる。ここでフォントエンジンとは、フォントファイル２０１から情報を取り出し、パスやビットマップデータを作成するソフトウェアを指す。

図２（Ｂ）は、イタリックの字体をフォントファイルに持たない場合に、イタリック字体を実現する方法の例である。この場合もまず、通常字体のフォントファイル２１１をフォントエンジンを用いて、通常字体のパスやビットマップ２１２を作成する。その後、独自のアルゴリズムで変換することにより、イタリック字体のテキスト２１３が取得できる。ここで、独自のアルゴリズムとは、その機能を備えるフォントエンジンの場合は、それを用いてもよく、その変換を以降では（イタリック）シミュレーションと呼ぶ。

ここで、図２（Ａ）の場合、フォントエンジンが異なっても大きな描画差分は発生しない。一方、図２（Ｂ）の場合、イタリックシミュレーションにはさまざまな方法が存在しており、シミュレーションするソフトウェアが異なるとその字体は大きく異なる。そのため、印刷時には同一のページや印刷ジョブ内では、シミュレーションは可能な限り同じ場所で行うことが望ましい。

しかしながら特許文献１では、シミュレーションを行うか否かを考慮していないため、プリンタドライバでシミュレーションが行われる場合と、プリンタでシミュレーションが行われる場合が共存する。従って、本来同じ字体のテキストで印刷されることを想定しているにも拘わらず、テキスト間で字体が異なる描画がなされてしまうことがある。また、特許文献１の方法では、同一の印刷データを異なるプリンタで印刷することで、各プリンタから出力される描画内容が異なってしまうことがある。

本発明の目的は、上記従来技術の問題点の少なくとも一つを解決することにある。

本発明の目的は、フォント情報の属性を含むテキストの印刷時に、印刷装置に依らず、同じ品質の文字を印刷できる技術を提供することにある。

上記目的を達成するために本発明の一態様に係る情報処理装置は以下のような構成を備える。即ち、
印刷装置に印刷ジョブを送信して印刷させる情報処理装置であって、
入力されたテキスト描画命令において、フォント情報の属性に基づくシミュレーションが必要か否かを判定する判定手段と、
前記判定手段により前記シミュレーションが必要であると判定された場合に、前記テキスト描画命令に基づくシミュレーションを実行して当該シミュレーションの結果を生成する生成手段と、
前記判定手段により前記シミュレーションが必要でないと判定された場合に、前記テキスト描画命令に基づいて制御コマンドを作成する作成手段と、
前記生成手段により生成された前記シミュレーションの結果に基づく制御コマンド、或いは前記作成手段により作成された制御コマンドを前記印刷装置に送信する送信手段と、を有することを特徴とする。

本発明によれば、フォント情報の属性を含むテキストの印刷時に、印刷装置に依らず、同じ品質の文字を印刷できるという効果がある。

本発明のその他の特徴及び利点は、添付図面を参照とした以下の説明により明らかになるであろう。なお、添付図面においては、同じ若しくは同様の構成には、同じ参照番号を付す。

添付図面は明細書に含まれ、その一部を構成し、本発明の実施形態を示し、その記述と共に本発明の原理を説明するために用いられる。
ビットマップダウンロードと、フォントダウンロード２つの処理例を説明する図。フォントファイルからイタリック字体を実現する２つの例を示す図。実施形態１に係る印刷システムの構成を説明する図。実施形態１に係る情報処理装置のＯＳの機能を説明する機能ブロック図。実施形態１に係るプリンタドライバによって実現される印刷処理を説明するフローチャート。図５のＳ５０２のＰＤＬ変換処理Ｓ５０２の詳細を説明するフローチャート。図６のＳ６０３のテキスト出力ＰＤＬ変換処理を説明するフローチャート。ＰＤＬコマンドの例を説明する図。本発明の実施形態２に係る、図６のＳ６０３のテキスト出力ＰＤＬ変換処理を説明するフローチャート。実施形態２に係るＰＤＬコマンド例として、ＰＣＬを例にパス描画化によるボールド／イタリックシミュレーションされた描画結果を表現したテキストのコマンド例を示す図。

以下、添付図面を参照して本発明の実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これら複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一もしくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

以下の実施形態では、実施形態に係る印刷処理システムにおいて、プリンタドライバにテキスト描画が入力された場合に、スタイルテキストを適切な場所で変換する論理を適合させた場合で説明する。

図３は、実施形態１に係る印刷システムの構成を説明する図である。

情報処理装置３００の中央処理装置（ＣＰＵ）３０１は、補助記憶装置３０３（ＨＤＤ，ＳＳＤ，ＦＤ，ＣＤ−ＲＯＭ，ＩＣメモリカード等の記憶媒体）からシステムプログラムやアプリケーションプログラムを主記憶装置（ＲＡＭ）３０２に展開して実行する。ＲＯＭ３０７は、ブートプログラムや各種設定情報などを不揮発に記憶している。これによりＣＰＵ３０１は、入力装置３０４から入力される情報を処理して、その処理結果を出力装置３０５や印刷装置３０６に出力する。尚、実施形態１では、出力装置３０５はディスプレイなどの表示装置とし、印刷装置３０６と区別する。また入力装置３０４は、キーボード、ポインティングデバイス等を有するものとする。更に、補助記憶装置３０３は、ハードディスク、光磁気ディスクを含むものであっても良く、或いはこれらの組み合わせであってもよい。また、それぞれの装置がネットワークを介して接続されていても良い。

図４は、実施形態１に係る情報処理装置３００のＯＳの機能を説明する機能ブロック図である。尚、これらの機能は、ＣＰＵ３０１がＲＡＭ３０３に展開したＯＳ４０１のプログラムを実行することにより実現される。また、この情報処理装置３００は、後述する印刷装置３０６とネットワークを介して接続されている。

プリンタドライバ４０２は、ＯＳ（オペレーティングシステム）４０１上で実行され、かつ、印刷装置３０６を制御するためのプログラムであり、ＣＰＵ３０１を各機能部として機能させるためのモジュールを含んでいる。例えば、Ｗｉｎｄｏｗｓ（登録商標）用プリンタドライバには、ＧＤＩ（Graphics Device Interface）プリンタドライバとＸＰＳ（XML Paper Specification）プリンタドライバ（以降、Ｖ４プリンタドライバ）がある。ＧＤＩプリンタドライバは、ＧＤＩを解釈してＰＤＬ（Printer Description Language）を生成するプリンタドライバである。Ｖ４プリンタドライバは、ＸＰＳを解釈してＰＤＬを生成するプリンタドライバである。従来型のアプリケーションは、印刷処理を行う際、ＧＤＩ描画命令をＧＤＩプリンタドライバに対して出力する。実施形態１では、このようなアプリケーションをＧＤＩアプリケーションと呼ぶ。一方、Ｖ４プリンタドライバに対応している新たなアプリケーションは、印刷処理を行う際に、Ｖ４プリンタドライバに対してＸＰＳ描画命令を直接出力する。このようなＸＰＳ描画命令を出力可能なアプリケーションをＸＰＳアプリケーションと呼ぶ。

ユーザインタフェース部４０３は、ユーザが印刷装置に対する設定など各種印刷設定を入力したり、印刷開始指示を行うのに使用される。レイアウト処理部４０４は、文書作成等を行うアプリケーションから、印刷時に指定される描画命令を受け、例えばＮ−ｕｐなどのレイアウトに関する変換を行う。

描画コマンド制御部４０５は、レイアウト処理部４０４により指定される描画命令を受け、印刷装置で処理できる描画データを作成する。この描画コマンド制御部４０５は、実施形態１に係る情報処理装置における重要な処理を含む。スタイル変換部４０６は、テキスト描画において、プリンタドライバ４０２でのシミュレーションが必要か否かを判定し、必要であればテキスト描画を行う。描画コマンド生成部４０７は、レイアウト処理部４０４から入力される描画命令に基づいて、ＰＤＬ等の描画コマンドを作成する。このシミュレーションとは、前述したように、例えばイタリックの字体をフォントファイルに持たない場合に、通常（所定）字体のフォントファイルをフォントエンジンを用いて通常（所定）字体のパスやビットマップを作成する。その後、独自のアルゴリズムで変換することにより、イタリック字体のテキストを取得する処理のことである。

印刷データ制御部４０８は、描画コマンド生成部４０７により作成された描画コマンドを印刷装置に対応した印刷データに変更し、更には印刷データ全体を制御する。具体的には、ＰＪＬなどの印刷ジョブ自体の設定などを制御する。データ送受信部４０９はＯＳ４０１の機能であり、印刷装置との間でデータの送受信を行う。データ送受信部４０９は、印刷データ制御部４０８で生成された印刷データを印刷装置３０６に送信する。印刷装置３０６は、接続された情報処理装置３００のデータ送受信部４０９から送信されてくる印刷データに応じた印刷処理を行う。

次に、プリンタドライバ４０２の動作を説明する。尚、以下に説明するフローチャートで示すプリンタドライバ４０２のプログラムは、補助記憶装置３０３に記憶されており、ＲＡＭ３０２に展開された後、ＣＰＵ３０１によって実行される。

図５は、実施形態１に係るプリンタドライバ４０２によって実現される印刷処理を説明するフローチャートである。この処理は、ユーザが情報処理装置でアプリケーションを起動して印刷を指示すると、補助記憶装置３０３に記憶されているプリンタドライバ４０２がＲＡＭ３０２に展開されてＣＰＵ３０１により実行される。そしてアプリケーションから渡される描画命令がプリンタドライバ４０２に渡されることにより、このフローチャートで示す処理が開始される。

まずＳ５０１でＣＰＵ３０１は、入力された描画命令を解析する。次にＳ５０２に進みＣＰＵ３０１は、図６を参照して後述するＰＤＬ変換処理を行う。このときＣＰＵ３０１は、プリンタドライバ４０２でシミュレーションを行う必要があるかを判定し、必要があればシミュレーションを実行して、印刷装置３０６が受け取ることができる描画コマンドに変換する。尚、描画コマンドは、具体的には、ＰＳ（Adobe社製）やＰＣＬ（HP社製）などのＰＤＬ描画コマンドを指す。実施形態１では、特に断りが無い限り、出力ＰＤＬはＰＣＬとする。

次にＳ５０３に進みＣＰＵ３０１は、その描画コマンドを、データ送受信部４０９を介して印刷装置３０６に送信する。これにより印刷装置３０６は、その描画コマンドを受信し、レンダリング及びハーフトーン化した後、記録媒体（シート）に印刷して印刷処理を実行する。

図６は、図５のＳ５０２のＰＤＬ変換処理Ｓ５０２の詳細を説明するフローチャートである。この処理は、ＣＰＵ３０１がスタイル変換部４０６として機能することにより実現される。

この処理では、ＣＰＵ３０１は、入力された各描画命令に対して、Ｓ６０１〜Ｓ６０５の処理を繰り返し実行する。まずＳ６０２でＣＰＵ３０１は、入力された描画命令が「テキスト描画」であるか否かを判定し、テキスト描画であると判定した場合はＳ６０３へ、そうでないと判定した場合はＳ６０４へ処理を進める。Ｓ６０３でＣＰＵ３０１は、図７を参照して後述する「テキスト出力ＰＤＬ変換処理」を行う。一方、Ｓ６０４でＣＰＵ３０１は、その描画コマンドを対応するＰＤＬに変換する。

図７は、図６のＳ６０３のテキスト出力ＰＤＬ変換処理を説明するフローチャートであ。この処理は、ＣＰＵ３０１がスタイル変換部４０６として機能することにより実現される。

まずＳ７０１でＣＰＵ３０１は、スタイルに基づいて、テキスト描画に際して、プリンタドライバ４０２でのシミュレーションが必要か否かの情報を取得する。ここで、スタイルが設定されていて、そのスタイルに合った字体がフォントファイルに存在すればシミュレーションは不要である。一方、そのスタイルに合った字体がフォントファイルに存在しない場合は、シミュレーションが必要となる。次にＳ７０２でＣＰＵ３０１は、上述の判定基準に従って、シミュレーションが必要か否かを判定する。ここでシミュレーションが必要と判定した場合はＳ７０３へ処理を進め、そうでないときはＳ７０５へ処理を進める。

Ｓ７０３でＣＰＵ３０１は、フォントファイルから取得したテキストの描画に対して、プリンタドライバ４０２によりボールド／イタリックシミュレーションを実行する。そしてＳ７０４に進みＣＰＵ３０１は、Ｓ７０３でボールド／イタリックシミュレーションを実行した描画結果をＰＤＬコマンドに変換して、この処理を終了する。この場合の具体的なコマンド例は、図８（Ａ）を参照して後述する。

一方、シミュレーション不要の場合はＳ７０５に進みＣＰＵ３０１は、フォント情報をＰＤＬコマンドに変換して、この処理を終了する。具体的なコマンド例は図８（Ｂ）を参照して説明する。

図８は、ＰＤＬコマンドの例を説明する図である。ここではＰＣＬを例に、テキストの描画方法として２つの例を示している。

図８（Ａ）は、ボールド／イタリックシミュレーションが実行された描画結果を表現したテキストのコマンド例を示す。ここではビットマップ化（ビットマップデータに変換）によるシミュレーションの例を示す。一方、図８（Ｂ）は、フォント情報で表現したテキストの描画コマンド例を示す。

ReadCharコマンド８０１，８１１は、描画するテキスト情報を伝えるコマンドである。ReadCharコマンドを補足する情報（属性情報）に、Format属性８０２，８１２が含まれている。この属性が図８（Ａ）のように「０」の場合はビットマップを示し、図８（Ｂ）のように「１」の場合は、フォント情報で表現したテキストの描画コマンドであることを示す。Bitmap Character Data８０３は、ビットマップの内容を示す属性情報である。参照番号８０４はテキストを表現するビットマップ情報を示す。

一方、図８（Ａ）の、True Type Glyph Data８１３は、フォント情報の内容を示す属性情報であり、参照番号８１４は、テキストを表現するフォント情報を示している。

このように、プリンタドライバ４０２に入力されたテキスト描画命令において、ボールド字体やイタリック字体へのシミュレーションが必要かどうか判定し、必要であればプリンタドライバ４０２が、シミュレーションを実行してビットマップ化する。これにより、印刷装置ごとにシミュレーション方法が異なることに起因する印刷品位の差異の発生を防止できるという効果がある。

尚、この実施形態１において、ビットマップ化によるボールド／イタリックシミュレーションを行う場合、テキストのサイズが大きい場合に、送信するデータサイズが大きくなってしまいＰＤＬの伝送速度が遅くなってしまう可能性がある。その解決策としてテキストのサイズに応じてシミュレーション方法を変更する実施形態２について図９を参照して説明する。尚、実施形態２に係る印刷システムの構成、及び情報処理装置の構成等は前述の実施形態１と同じであるため、その説明を省略する。

図９は、本発明の実施形態２に係る、図６のＳ６０３のテキスト出力ＰＤＬ変換処理を説明するフローチャートである。この処理は、ＣＰＵ３０１がスタイル変換部４０６として機能することにより実現される。

Ｓ９０１でＣＰＵ３０１は、スタイルのシミュレーションが必要か否かの情報を取得する。ここで、スタイルが設定されていて、そのスタイルに合った字体がフォントファイルに存在すればシミュレーションは不要であり、存在しない場合にはシミュレーションが必要となる。こうしてＳ９０２でＣＰＵ３０１は、スタイルに合った字体がフォントファイルに存在するかどうかにより、シミュレーションが必要か否かを判定する。ここでシミュレーションが必要と判定するとＳ９０３へ処理を進め、そうでないときはＳ９０７へ処理を進める。Ｓ９０７でＣＰＵ３０１は、前述の図７のＳ７０５と同様に、フォント情報をＰＤＬコマンドに変換して、この処理を終了する。具体的なコマンド例は図８（Ｂ）で説明した通りである。

一方、Ｓ９０３でＣＰＵ３０１は、テキストの文字サイズが閾値よりも大きいかどうかを判定し、閾値よりも大きい場合はＳ９０４へ処理を進め、そうでない場合はＳ９０５へ処理を進める。Ｓ９０５でＣＰＵ３０１は、図７のＳ７０３と同様に、フォントファイルから取得したテキストの描画に対して、ボールド／イタリックシミュレーションを実行してビットマップ化する。そしてＳ９０６に進みＣＰＵ３０１は、Ｓ７０５でボールド／イタリックシミュレーションを実行した描画結果をＰＤＬコマンドに変換して、この処理を終了する。

一方、テキストの文字サイズが閾値よりも大きいときはＳ９０４に進みＣＰＵ３０１は、フォントファイルから取得したテキストの描画に対して、パス描画化によるボールド／イタリックシミュレーションを実行してＳ９０６へ処理を進める。そしてＳ９０６でＣＰＵ３０１は、Ｓ９０４でボールド／イタリックシミュレーションした描画結果をＰＤＬコマンドに変換する。

具体的なコマンド例はパス描画化された描画については、図１０を参照して後述する。尚、ビットマップ化された描画については、図８（Ａ）で説明した通りである。

図１０は、実施形態２に係るＰＤＬコマンド例として、ＰＣＬを例にパス描画化によるボールド／イタリックシミュレーションされた描画結果を表現したテキストのコマンド例を示す図である。

LineRelPathコマンド１００１は、描画するパス情報を伝えるコマンドである。LineRelPathコマンド１００１の属性情報には、パス描画の座標を格納するものがあり、参照番号１００２で示すように、パス描画の座標列を格納する。

以上説明したように実施形態２によれば、テキストの文字サイズが閾値よりも大きい場合は、ビットマップ化ではなく、パス描画化による描画結果を表現したテキストのコマンドで送信する。これにより、テキストのサイズが大きい場合に、送信するデータサイズが大きくなってＰＤＬの伝送速度が遅くなるといった不具合を防止できる。

以上説明したように実施形態によれば、プリンタドライバに入力されたテキスト描画に対して、ボールド字体やイタリック字体へのシミュレーションが必要であるかを判定し、必要であればプリンタドライバ側でシミュレーションを実行することにより、プリンタ間のシミュレーション方法の違いで発生する品質差分を防ぐことが可能となる。更に、シミュレーション方法をテキストのサイズによって切り替えることにより、データサイズを小さくし伝送速度を抑えることが可能となる。結果的に印刷時間の高速化となる。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

本発明は上記実施形態に制限されるものではなく、本発明の精神及び範囲から逸脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために、以下の請求項を添付する。

３００…情報処理装置、３０１…中央処理装置（ＣＰＵ）、３０２…主記憶装置（ＲＡＭ）、３０６…印刷装置、４０２…描画コマンド制御部、４０６…スタイル変換部

Claims

印刷装置に印刷ジョブを送信して印刷させる情報処理装置であって、
入力されたテキスト描画命令において、フォント情報の属性に基づくシミュレーションが必要か否かを判定する判定手段と、
前記判定手段により前記シミュレーションが必要であると判定された場合に、前記テキスト描画命令に基づくシミュレーションを実行して当該シミュレーションの結果を生成する生成手段と、
前記判定手段により前記シミュレーションが必要でないと判定された場合に、前記テキスト描画命令に基づいて制御コマンドを作成する作成手段と、
前記生成手段により生成された前記シミュレーションの結果に基づく制御コマンド、或いは前記作成手段により作成された制御コマンドを前記印刷装置に送信する送信手段と、
を有することを特徴とする情報処理装置。
前記判定手段は、前記フォント情報の属性に対応するフォントファイルが存在せず、かつ前記テキスト描画命令において前記フォント情報の属性が指定されている場合に、前記フォント情報の属性のシミュレーションが必要であると判定することを特徴とする請求項１に記載の情報処理装置。
前記生成手段は、前記フォント情報の属性に対応するビットマップ化したデータを前記シミュレーションの結果として生成することを特徴とする請求項１又は２に記載の情報処理装置。
前記生成手段は、前記フォント情報の属性に基づくパス描画化したデータを前記シミュレーションの結果として生成することを特徴とする請求項１又は２に記載の情報処理装置。
前記作成手段は、前記テキスト描画命令に基づいてページ記述言語（ＰＤＬ）を作成することを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
前記シミュレーションは、所定の字体のフォントファイルから当該所定の字体のパスやビットマップデータを作成し、当該パスやビットマップデータを前記フォント情報の属性に対応する字体のパスやビットマップデータに変換する処理であることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
前記属性は、ボールドやイタリックを含むスタイルと呼ばれる属性であることを特徴とする請求項１乃至６のいずれか１項に記載の情報処理装置。
前記判定手段が、前記シミュレーションが必要と判定した場合、前記テキスト描画命令に含まれる文字のサイズが閾値よりも大きいかどうかに応じて、前記生成手段は、前記フォント情報の属性に対応するビットマップ化したデータを前記シミュレーションの結果として生成するか、或いは前記フォント情報の属性に基づくパス描画化したデータを前記シミュレーションの結果として生成することを特徴とする請求項１乃至７のいずれか１項に記載の情報処理装置。
印刷装置に印刷ジョブを送信して印刷させる情報処理装置を制御する制御方法であって、
入力されたテキスト描画命令において、フォント情報の属性に基づくシミュレーションが必要か否かを判定する判定工程と、
前記判定工程で前記シミュレーションが必要であると判定された場合に、前記テキスト描画命令に基づくシミュレーションを実行して当該シミュレーションの結果を生成する生成工程と、
前記判定工程で前記シミュレーションが必要でないと判定された場合に、前記テキスト描画命令に基づいて制御コマンドを作成する作成工程と、
前記生成工程で生成された前記シミュレーションの結果に基づく制御コマンド、或いは前記作成工程で作成された制御コマンドを前記印刷装置に送信する送信工程と、
を有することを特徴とする制御方法。
コンピュータを、請求項１乃至８のいずれか１項に記載の情報処理装置の各手段として機能させるためのプログラム。