JP2019148846A - 情報処理装置、情報処理方法及びプログラム - Google Patents

Abstract

【課題】バーコードフォントを用いて印刷するための描画データをＸＰＳプリントパスで処理する場合において、ＧＤＩプリントパスと同じ出力結果を得ることができるようにする。【解決手段】情報処理装置が、アプリケーションから入力されたＧＤＩ形式の描画データをＸＰＳ形式の描画データに変換する変換手段と、前記ＸＰＳ形式の描画データをレンダリングしてＰＤＬデータに変換するレンダリング手段と、を備え、前記レンダリング手段は、前記ＸＰＳ形式の描画データ内の描画対象のオブジェクトが、フォントを用いて描画するテキスト属性の文字オブジェクトである場合、フォントデータから算出した文字送り幅に基づいてレンダリングすることを特徴とする。【選択図】図５

Description

本発明は、グラフィックスエンジンを用いて印刷処理を行なう情報処理装置における描画制御技術に関する。

Ｍｉｃｒｏｓｏｆｔ社のＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムにおいて動作するアプリケーションから文書をプリンタにて印刷するための処理フローとして、次の２つが存在する。すなわち、ＧＤＩ（Ｇｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ）プリントパス、および、ＸＰＳ（ＸＭＬ Ｐａｐｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）プリントパスである。ＧＤＩプリントパスとＸＰＳプリントパスとは排他的な関係にあるわけではなく、例えばアプリケーションがＧＤＩを使って生成したＧＤＩ形式の描画データをＸＰＳ形式の描画データに変換してＸＰＳ用のプリンタドライバで印刷ジョブにすることが可能である。この描画データの変換は、ＭＸＤＣ（Ｍｉｃｒｏｓｏｆｔ ＸＰＳ Ｄｏｃｕｍｅｎｔ Ｃｏｎｖｅｒｔｅｒ）と呼ばれる変換モジュールによってなされる。

ここで、バーコードフォントを用いて作成された文書を、ＭＸＤＣを介して生成された印刷ジョブに従って印刷する場合、バーコードを構成するバー同士の間隔がずれてしまう場合がある。これは、ＭＸＤＣにおける描画データ変換時の演算誤差に起因するものである。バーコードフォントを用いて作成した文書を適切に印刷するための技術としては、例えば特許文献１がある。特許文献１の概要は以下のとおりである。まず、印刷対象の画像情報にバーコード画像が含まれている場合、アプリケーションは、ＧＤＩを介してプリンタドライバに渡す画像情報とは別に、バーコード識別情報を記憶部に記憶させておく。そして、プリンタドライバは、ＧＤＩを介して取得する画像情報にバーコードフォントが含まれる場合、記憶部に記憶されているバーコード識別情報に基づいて、そのバーコード部分の制御コマンドを生成し、当該生成した制御コマンドを用いてバーコードを印刷する、というものである。

特開２０１３−２５７８０５号公報

しかしながら、上記特許文献１の技術は、バーコード識別情報を別途記憶部に記憶させる機能をアプリケーションが備えている必要があり、このような機能を有さない一般的なアプリケーションでは使用できない。

本発明に係る情報処理装置は、アプリケーションから入力されたＧＤＩ形式の描画データをＸＰＳ形式の描画データに変換する変換手段と、前記ＸＰＳ形式の描画データをレンダリングしてＰＤＬデータに変換するレンダリング手段と、を備え、前記レンダリング手段は、前記ＸＰＳ形式の描画データ内の描画対象のオブジェクトが、フォントを用いて描画するテキスト属性の文字オブジェクトである場合、フォントデータから算出した文字送り幅に基づいてレンダリングすることを特徴とする。

本発明によれば、バーコードフォントを用いて印刷するための描画データをＸＰＳプリントパスで処理する場合において、ＧＤＩプリントパスと同じ出力結果を得ることができる。

ＰＣのハードウェア構成の一例を示すブロック図 Ｖ４ドライバを用いた印刷ジョブの生成処理に関わるソフトウェア構成の一例を示す図 レンダリングフィルタ２０５の内部構成を示す機能ブロック図 ＣＯＤＥ１２８規格の説明図 バーコード形成時に適切なスペース幅を実現するレンダリング処理の流れを示すフローチャート （ａ）はバーコードが配置された文書の一例を示す図、（ｂ）はバーコードフォントを用いて描画することを指定したＸＰＳデータの一例を示す図 バーコードの４文字分の描画結果を示す図 文字送り幅、オフセット、スペース幅をまとめた表 変形例に係る、（ａ）はバーコードが配置された文書の一例を示す図、（ｂ）はバーコードフォントを用いて描画することを指定したＸＰＳデータの一例を示す図 変形例に係る、文字送り幅の算出の詳細を示すフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。なお、実施形態は、本発明を限定するものではなく、また、実施形態で説明されている全ての構成が本発明の課題を解決するための手段に必須であるとは限らない。

実施形態１

図１は、本実施形態に係る、印刷ジョブを生成する情報処理装置としてのＰＣのハードウェア構成の一例を示すブロック図である。ＰＣ１０は、コントローラ１００、入力デバイス１１０、ディスプレイ１２０、外部メモリ１３０で構成される。コントローラ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ネットワークＩ／Ｆ１０５、入力Ｉ／Ｆ１０６、ディスプレイＩ／Ｆ１０７、外部メモリＩ／Ｆ１０８で構成され、システムバス１０４を介して相互に接続される。

コントローラ１００は、ＰＣ１０を統括的に制御する。ＣＰＵ１０１は、ＲＡＭ１０２に記憶されているプログラムに従って、システムバス１０４に接続される各部を制御する。ＲＡＭ１０２は、ＣＰＵ１０１の主メモリ、ワークエリア等としても機能する。ＲＯＭ１０３は、各種プログラム及びデータを格納しており、各種フォントを記憶するフォントＲＯＭ１０３ａ、ブートプログラムやＢＩＯＳ等を記憶するプログラムＲＯＭ１０３ｂ、及び各種データを記憶するデータＲＯＭ１０３ｃに区分けして構成される。ネットワークＩ／Ｆ１０５は、ＬＡＮ３０を介してプリンタ２０等の外部装置と通信処理を行なうインタフェースである。入力Ｉ／Ｆ１０６は、キーボードやポインティングデバイス（マウス）といった入力デバイス１１０を使用したユーザ入力を受け付けるインタフェースである。ディスプレイＩ／Ｆ１０７は、ディスプレイ１２０への表示処理を制御するインタフェースである。外部メモリＩ／Ｆ１０８は、例えばＨＤＤやＳＳＤといった外部メモリ１３０とのアクセス制御を行うインタフェースである。外部メモリ１３０には、オペレーティングシステム（ＯＳ）や印刷処理を担う各種ソフトウェア、さらに、ユーザファイル、編集ファイル等の各種データが格納される。なお、ＯＳは本実施形態ではＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓを使用するものとする。

背景技術で述べたとおり、Ｗｉｎｄｏｗｓ８（登録商標）以降は、ＸＰＳプリントパスと呼ばれる印刷処理フローが加わった。ＸＰＳプリントパスでは、ＸＰＳに対応したアプリケーションでＸＰＳ形式の描画データが生成され、Ｖｅｒｓｉｏｎ４プリンタドライバ（以下、「Ｖ４ドライバ」）にてＰＤＬデータに変換される。本発明は、従来からのＧＤＩに対応したアプリケーションにおいてＧＤＩ形式の描画データを生成し、それがＭＸＤＣでＸＰＳ形式の描画データに変換されてＶ４ドライバに入力される場面を前提としている。図２は、ＰＣ１０における、Ｖ４ドライバを用いた印刷ジョブの生成処理に関わるソフトウェア構成の一例を示す図である。以下、図２に沿って詳しく説明する。

アプリケーション２０１は、ユーザが文書を作成し印刷指示等を与えるためのＧＤＩに対応したアプリケーションソフトウェアである。ユーザによって印刷指示が与えられると、アプリケーション２０１はＧＤＩを利用して、指定された文書についてのＧＤＩ形式の描画データを生成する。生成されたＧＤＩ形式の描画データはＭＸＤＣ２０２に送られる。本実施形態では、ＯＳにインストールされたバーコードフォントを用いた文書をアプリケーション２０１が作成し、フォント情報を含んだＧＤＩ形式の描画データをＭＸＤＣ２０２へ出力する。ＭＸＤＣ２０２は、受け取ったＧＤＩ形式の描画データをＸＰＳ形式に変換する。具体的には、フォント情報に基づき、フォント名やＧｌｙｐｈＩｎｄｅｘ（以下、「Ｇｉｄ」と表記）などが記載されたＸＰＳ形式の描画データに変換する。そして、変換したＸＰＳ形式の描画データを、Ｖ４ドライバ２０３に出力する。Ｖ４ドライバ２０３は、ＸＰＳプリントフィルタパイプライン（以下、「フィルタパイプライン」）と呼ばれるプログラミングモデルに従って、出力指示に応じたＰＤＬデータを生成する。フィルタパイプライン２０４における印刷処理の単位はフィルタと呼ばれ、単一または複数のフィルタが、フィルタパイプライン２０４によって順にリンクされて実行される。すなわち、あるフィルタの出力がその次に連結されたフィルタの入力となり、各フィルタが順次処理を実行することによって最終的な出力物であるＰＤＬデータ（印刷ジョブ）を生成する仕組みになっている。本実施形態においては、ＸＰＳ形式の描画データからＰＤＬデータを生成する単一のレンダリングフィルタ２０５でフィルタパイプライン２０４が構成されるものとする。レンダリングフィルタ２０５では、ＭＸＤＣ２０２から入力されたＸＰＳ形式の描画コマンドを解析し、各オブジェクトに対して拡大、縮小、回転などの画像処理を必要に応じて施した上でレンダリング処理を行って、ＰＤＬデータを生成する。この際、フォント処理部２０６を介してフォントラスタライザ２０７を利用して、ＯＳにインストールされたフォントデータからフォント情報を取得し、文字の描画を行う。以下の表１に、フォントデータの内容の一例を示す。ただし、本実施形態と関連しない項目は省略している。

上記表１において、項目Ｇｉｄは、フォントが持つ各文字に割り振られた固有の番号を表す。また、項目ＷＸは、次の文字への送り幅（１００／ＵＰＭ単位）を表す。また、項目ＢＲＯＸは、実際に描かれる文字の外接矩形の左上のＸ座標とＹ座標を（ｘ０，ｙ０）、右上のＸ座標とＹ座標を（ｘ１，ｙ１）として、当該文字のバウンディングボックスを表す。なお、ＵＰＭはunits-per-emの略であり、文字サイズの基準となる１emに相当するユニット数を表す。

レンダリングフィルタ２０５におけるレンダリング処理の詳細は後述する。レンダリングフィルタ２０５によって生成されたＰＤＬデータは、ポートモニタ２０８に出力される。ポートモニタ２０８は、ＰＤＬデータをプリンタ２０にＬＡＮ３０を通じて送信する。

＜レンダリングフィルタの構成＞
図３は、レンダリングフィルタ２０５の内部構成を示す機能ブロック図である。レンダリングフィルタ２０５は、ＸＰＳ解析部３０１、画像処理部３０２、ＰＤＬ生成部３０３の３つの処理モジュールからなる。以下、各処理モジュールについて説明する。

ＸＰＳ解析部３０１は、ＭＸＤＣ２０２から入力されたＸＰＳ形式の描画コマンド群からなるデータ（以下、「ＸＰＳデータ」と呼ぶ）を解析して、１又は複数のオブジェクトを描画するためのデータ（以下、「オブジェクトデータ」と呼ぶ）を順次出力する。ここで、各オブジェクトは、写真（イメージ）、図形（グラフィック）、文字（テキスト）といった属性を持っている。ＸＰＳ解析部３０１は、テキスト属性のオブジェクトを描画する場合は、フォント処理部２０６を利用して、ＸＰＳデータに記載されたフォント名に基づきフォントデータへアクセスする。そして、文字のグリフの情報や次の文字への送り幅の情報などを取得する。

画像処理部３０２は、ＸＰＳ解析部３０１から入力されたオブジェクトデータに対して、拡大、縮小、回転などの画像処理を必要に応じて施して、オブジェクトデータをＰＤＬ生成部３０３に渡す。このとき、文字フォントについては、フォント処理部２０６を通じてフォントラスタライザ２０７を用いて、ラスタライズを行う。ＰＤＬ生成部３０３は、画像処理部３０２から入力される１又は複数のオブジェクトデータに基づき、ＰＤＬデータを生成する。

なお、レンダリングフィルタ２０５が扱うＸＰＳデータ、オブジェクトデータ及びＰＤＬデータは、いずれも印刷対象文書に含まれる全描画対象情報の集合体であり、全オブジェクトの出力順序も示されている。

＜バーコード描画＞
続いて、本発明の前提である、バーコードフォントを用いたバーコード描画について簡単に説明する。バーコードフォントとは、数値や文字列の値をバーコードの書式に変換して表示するためのフォントを指す。以下では、ＸＰＳプリントパスにてバーコードを描画する場合におけるバー同士の間隔（スペース幅）をバーコードとして理想的な間隔に保ち、ＧＤＩプリントパスでのバーコード描画と同等に保つ手法について説明する。

そもそも、紙等に印字されたバーコード様のものがバーコードとして認識されるかどうか（バーコード認識率）は、バーの幅と隣り合うバー間のスペース幅が、規定通りの比率で現れるか否かにかかっている。例えば、ＣＯＤＥ１２８規格では、図４に示すとおり、各４種類あるバーの幅とスペース幅がそれぞれ１：２：３：４で描くことが規定されている。このように所定の規格で定められたバーコードを印刷出力する場合において、隣り合う２本のバーの間隔、つまりスペースの開始位置と終了位置をそれぞれ示す座標が、Ｖ３ドライバとＶ４ドライバとで異なってしまう現象が起きることが分かっている。これは、Ｖ３ドライバとＶ４ドライバとでは、使用する座標系が異なることに加え、ＭＸＤＣ２０２における変換処理において、次の文字への送り幅（以下、「文字送り幅」と呼ぶ）が整数に丸められてしまうことが主な原因と考えられる。これにより、バーやスペースの描画開始位置がずれて、スペースの幅にゆらぎが出てしまい、Ｖ３ドライバによる出力結果と同じ出力結果がＶ４ドライバでは得られないという問題が起こり得る。そこで本実施形態では、フォントデータ内の文字送り幅の情報から、Ｖ４ドライバで出力する場合の適切な文字送り幅を求め直し、これによりＶ３ドライバによる場合と同等の出力結果を得る方法を説明する。

＜本発明の課題の確認＞
フォントを使用して描画される文字オブジェクトの場合、そのフォントデータの場所が描画コマンド内で指定されている。図６（ａ）はページの左上と右下にそれぞれバーコード６０１及び６０２が配置された文書の一例を示し、同（ｂ）は当該２つのバーコード６０１及び６０２を、バーコードフォントを用いて描画することを指定したＸＰＳデータを示す。なお、左上のバーコード６０１を「ＴＬバーコード」、右下のバーコード６０２を「ＢＲバーコード」と呼ぶこととする。また、ＴＬバーコード６０１に対応する描画コマンド６１０を「ＸＰＳコマンドＴＬ」、ＢＲバーコード６０２に対応する描画コマンド６２０を「ＸＰＳコマンドＢＲ」と呼ぶこととする。ＸＰＳコマンドＴＬ６１０、ＸＰＳコマンドＢＲ６２０には、それぞれ使用するフォントデータ、文字列、文字の開始位置、拡大率、文字コード、文字送り幅などの情報が含まれる。

図６（ｂ）において、“Ｃａｎｖａｓ”タグ内の“ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ”は、Ｃａｎｖａｓの拡大・縮小率、オフセット位置を示す。また、“Ｇｌｙｐｈｓ”タグ内の“ＦｏｎｔＵｒｉ”は、文字のレンダリングに使用されるフォントデータのある場所を示している。そして、“ＵｎｉｃｏｄｅＳｔｒｉｎｇ”はＦｏｎｔＵｒｉで特定されるフォントを用いて描画したい文字列を示し、“Ｉｎｄｉｃｅｓ”はＵｎｉｃｏｄｅＳｔｒｉｎｇで定義した文字列をどのようにレンダリングするかを定義している。文字毎の定義はセミコロンで囲まれ、その中で４つの要素がカンマ区切りで表現される。この例では、先頭から順に、フォントが持つ各文字に割り振られた固有の番号であるＧｉｄ、次の文字への文字送り幅を表すＡｄｖａｎｃｅＷｉｄｔｈを要素として持っている。“ＦｏｎｔＲｅｎｄｅｒｉｎｇＥｍＳｉｚｅ”は、描画サーフェイスの単位 （既定値は９６ｄｐｉ）におけるフォントサイズを示している。“ＯｒｉｇｉｎＸ”は文字の開始位置のＸ座標を示し、“ＯｒｉｇｉｎＹ”は文字の開始位置のＹ座標を示す。“Ｆｉｌｌ”は文字の色情報を示す。“ＲｅｎｄｅｒＴｒａｎｓｆｏｒｍ”は、文字の拡大・縮小率やオフセット位置の情報を示す。なお、図６（ａ）のＴＬバーコード６０１とＢＲバーコード６０２とは同じフォントデータを使用する同じ内容のバーコードであり、 描画位置だけが異なるものとする。図７は、ＴＬバーコード６０１とＢＲバーコード６０２における１文字目から４文字目までの描画結果を示す拡大図である。両矢印７１１は１番目の文字７０１から２番目の文字７０２への文字送り幅を、両矢印７１２は２番目の文字７０２から３番目の文字７０３への文字送り幅を、両矢印７１３は３番目の文字７０３から４番目の文字７０４への文字送り幅をそれぞれ示している。文字開始位置から必ずしも描画が開始される（つまり画素が黒く塗られる）わけではなく、例えば２番目の文字７０２の文字開始位置は矢印７０２ａの位置であるが、黒く塗られる描画開始位置は矢印７０２ｂの位置となる。同様に、例えば４番目の文字７０４の文字開始位置は矢印７０４ａの位置で、黒く塗られる描画開始位置は矢印７０４ｂの位置となる。フォント描画においては、文字間のスペースが期待通りの幅を保てるかどうかが、バーコードの性能に関連して重要となる。図７の例では、ページ内の異なる位置に配置されているＴＬバーコード６０１及びＢＲバーコード６０２のいずれにおいても、スペース幅Ｗ１２、Ｗ２３、Ｗ３４が、ＧＤＩプリントパスでのスペース幅と同じであることが要求される。この場合において、ＸＰＳデータから、デバイス解像度における文字送り幅を算出した場合には、以下のような問題が生じることが発明者による実験によって明らかとなった。以下、図６（ｂ）におけるＸＰＳコマンドＴＬ６１０を例にとって、ＸＰＳデータからの文字送り幅の算出について説明する。なお、以下では、ＸＰＳデータから算出される文字送り幅を「ＸＰＳ文字送り幅」と呼ぶこととする。

まず、Ｉｎｄｉｃｅｓの要素６１１には「18,16」と記載されている。これは、Ｇｉｄが“18”で、ＡｄｖａｎｃｅＷｉｄｔｈが“16”であることを示している。つまり、１番目の文字７０１として、ＦｏｎｔＵｒｉが示すフォントデータにおけるＧｉｄ“18”で特定される文字を描画し、当該文字の送り幅７１１は“16”とすることが指定されている。なお、Ｇｉｄの各番号で特定される各文字は、実際には所定のキャラクタマップ変換を経て描画されるものであるが、本発明の主眼ではないので説明を省略している。バーコードを構成する、バーとスペースの組み合わせからなる単位文字がこのようにして定義され、これにより例えば文字７０１のような描画結果が得られる。

ここで、出力解像度が６００ｄｐｉのとき、１番目の文字７０１における描画開始位置のＸ座標（ｐｉｘｅｌ換算）は、以下の式（１）で求められる。上述のとおり、この場合の描画開始位置は、実際に黒く塗られるバー部分の描画が開始される位置を意味する。１番目の文字７０１の場合はバーから始まるので、描画開始位置と文字開始位置とが一致することになる。これに対し、２番目の文字７０２の場合はスペースから始まるので、描画開始位置と文字開始位置とは一致しないことになる。

描画開始Ｘ座標＝{OriginX * (GryphsRenderTransformの1要素目) +
(CanvasRenderTransformのOffsetX)} *（600dpi / 96dpi）
・・・式（１）
上記式（１）から、１番目の文字７０１における描画開始位置（＝文字開始位置）のＸ座標は、(181.92 * 0.116986 + 19.2) * (600 / 96) = 253.013082 (px)となる。

そして、文字間のＸＰＳ文字送り幅（ピクセル換算）は、以下の式（２）によって求められる。

ＸＰＳ文字送り幅＝AdvanceWidth * (FontRenderingEmSize / 100) *
(GlyphsRenderTransformの1要素目) * (600dpi / 96dpi)
・・・式（２）
よって、１文字目から２文字目へのＸＰＳ文字送り幅は、上記式（２）より、16 *（160 / 100）* 0.116986 *（600 / 96）= 18.71776 (px)となる。

続いて、２番目の文字７０２における描画開始位置７０２ｂの算出方法を説明する。ここで、文字開始位置から、実際に黒く描かれる描画開始位置までの距離を「オフセット」と定義する。すると、オフセットは、以下の式（３）で求められる。

オフセット＝ bbox_x0 * (FontRenderingEmSize / 1000) *
（GryphsRenderTransformの1要素目) * (600dpi / 96dpi)
・・・式（３）
よって、２番目の文字７０２のオフセット２（文字開始位置７０２ａと描画開始位置７０２ｂとの距離）は、表１と上記式（３）より、80 * (160 / 1000) * 0.116986 * (600 / 96) = 9.3588 (px)となる。

そして、文字７０１と文字７０２との間にあるスペース幅Ｗ１２は、ＸＰＳ文字送り幅にオフセット値を加えた値、18.7177 + 9.3588 = 28.0765 (px) となる。

同様に、２番目の文字７０２と３番目の文字７０３との間、３番目の文字７０３と４番目の文字７０４との間における、それぞれのＸＰＳ文字送り幅とスペース幅も算出することができる。図８は、図７に示す４つの文字７０１〜７０４に関する、文字送り幅、オフセット、スペース幅をまとめた表である。そして、図８の表において、行８０２にはＸＰＳコマンドＴＬ６１０からの算出結果が、行８０３にはＸＰＳコマンドＢＲ６２０からの算出結果がそれぞれ示されている。また、図８の行８０１には、ＧＤＩ形式の描画コマンドから得られる各文字の文字送り幅、オフセット、スペース幅が記載されている。ＧＤＩ形式の描画コマンドでは、各値は整数値で得られる。行８０２及び８０３を見ると、ＸＰＳデータから算出したＸＰＳ文字送り幅を使ってバーコードを描画した場合、当該バーコードの印字位置によってはスペース幅がＧＤＩプリントパスとは一致せず、ズレが生じていることが分かる。例えば、スペース幅Ｗ２３に着目すると、ＢＲバーコード６０２におけるこれらの値は33.926（px）であるのに対し、ＧＤＩプリントパスにおけるこれらの値は33（px）である。よって、およそ１ピクセル分だけ、ＸＰＳデータから算出したスペース幅の方が大きい。また、スペース幅Ｗ３４に着目すると、ＢＲバーコード６０２における値は31.586（px）であるのに対し、ＧＤＩプリントパスにおける値は32（px）であるので、およそ0.4ピクセル分だけ、ＸＰＳデータから算出したスペース幅の方が小さい。このようなズレは、行８０２及び８０３に記載の文字送り幅、オフセット、スペース幅の各値に対して、同じ内容の丸め処理を一律に行っても解消できない。

例えば、行８０２及び８０３に記載の各値に対し、小数点以下を四捨五入する丸め処理を一律に適用したとする。この場合、例えばスペース幅Ｗ３４について、行８０２における値“32.756”は四捨五入によって33（px）となってしまい、行８０１における32（px）と異なる結果になる。また、スペース幅Ｗ２３についても、行８０３における値“33.926”は四捨五入によって34（px）となってしまい、行８０１における33（px）と異なる結果となる。

次に、行８０２及び８０３に記載の各値に対し、小数点以下を切り上げる丸め処理を一律に適用したとする。この場合、例えばスペース幅Ｗ１２について、行８０２及び８０３における値“28.077”はいずれも切り上げによって29（px）となってしまい、行８０１における28（px）と異なる結果となる。また、オフセット２についても、行８０２及び８０３における値“9.359”がいずれも切り上げによって10（px）となってしまい、行８０１における9（px）と異なる結果となる。

そして、行８０２及び８０３に記載の各値に対し、小数点以下を切り捨てる丸め処理を一律に適用したとする。この場合、例えばスペース幅Ｗ２３について、行８０２における値“32.756”は切り捨てによって32（px）となってしまい、行８０１における33（px）と異なる結果となる。また、スペース幅３４についても、行８０３における値“31.586”が切り捨てによって31（px）となってしまい、行８０１における32（px）と異なる結果となる。

以上のとおり、四捨五入、切り捨て、切り上げのいずれかを一律に適用するだけでは、行８０１に記載のＧＤＩプリントパスにおける文字送り幅、オフセット、スペース幅の各値とＸＰＳデータから算出されたそれらの値とを一致させることはできない。

＜バーコード付き文書のレンダンリング処理＞
図５は、本実施形態に係る、バーコード形成時に適切なスペース幅を実現するレンダリング処理の流れを示すフローチャートである。上述した問題を踏まえ、ＭＸＤＣから入力された、バーコードフォントを使用したバーコード付き文書の印刷指示であるＸＰＳデータをＶ４ドライバで処理するに際し、Ｖ３ドライバのときと同等の出力結果を得られるようにしている。以下、図５のフローに沿って説明する。

ステップ５０１では、ＸＰＳ解析部３０１において、ＭＸＤＣ２０２から入力されたバーコード付き文書の印刷を指示するＸＰＳデータに対し、フォントを使用するテキスト属性の描画コマンドの探索が実行される。具体的には、バーコードフォントを利用したバーコード印刷の場合に必ず含まれる＜Ｇｌｙｐｈｓ＞タグの有無がチェックされる。例えば、同じバーコード印刷であっても、パスを利用したグラフィック属性のオブジェクトとしてバーコードを描画する場合や、ビットマップ画像によるイメージ属性のオブジェクトとしてバーコードを描画する場合は、上述した問題は生じない。したがって、本ステップにおいて、ＸＰＳデータ内に＜Ｇｌｙｐｈｓ＞タグがあるか否かがチェックされる。

ステップ５０２では、ステップ５０１における探索結果に応じて処理の切り分けがなされる。ＸＰＳデータ内に＜Ｇｌｙｐｈｓ＞タグがない場合はステップ５０５へ進み、＜Ｇｌｙｐｈｓ＞タグがある場合はステップ５０３へ進む。

ステップ５０３では、ＸＰＳ解析部３０１において、デバイス解像度における文字送り幅とオフセットが、ＸＰＳデータからではなく、フォントデータから算出される。以下、前述の図６（ｂ）のＸＰＳデータにおけるＸＰＳコマンドＴＬ６１０を例にとって、フォントデータから文字送り幅をどのように算出するのかを説明する。なお、以下では、フォントデータから算出される文字送り幅を「フォント文字送り幅」と呼ぶこととする。

前述のとおり、１番目の文字７０１に対応する要素６１１におけるＧｉｄは“18”であり、ＷＸで示される文字送り幅は“160”であることがわかる（上記表１を参照）。ここで、文字送り幅は「100/UPM」単位であり、文字のＵＰＭは“1000”とする。出力解像度が600ｄｐｉのとき、１番目の文字７０１における描画開始位置のＸ座標（Pixel換算）は、以下の式（４）で求められる。
フォント文字送り幅＝WX * (100/UPM) * (FontRederingEmSize / 100) *
(GlyphsRenderTransformの１要素目) * (600dpi / 96dpi)
・・・式（４）

よって、１番目の文字７０１から２番目の文字７０２へのフォント文字送り幅７１１は、上記式（４）より、160 * (100/1000) * (160/100) * 0.116986 * (600/96) = 18.7177（px）となる。また、２番目の文字７０２における描画開始位置７０２ｂ（＝オフセット２）も上記表１と上記式（３）から同様に求めることができ、9.3588（px）となる。よって、スペース幅Ｗ１２も、ＸＰＳデータから算出した結果と同じ、28.0765（px）となる。そして、要素６１２のＧｉｄ“65”に対応する文字についても表１のＷＸで示す文字送り幅“280”を用いて、フォント文字送り幅７１２、オフセット３、スペース幅Ｗ２３が同様に算出される。また、要素６１３のＧｉｄ“36”に対応する文字についても表１のＷＸで示す文字送り幅“240”を用いて、フォント文字送り幅７１３、オフセット４、スペース幅Ｗ３４が同様に算出される。これらの算出結果が、図８の表における行８０４の「フォント（実数）」に示されている。

ステップ５０４では、ＸＰＳデータ内に未処理の＜Ｇｌｙｐｈｓ＞タグが残っていないかが判定される。未処理の＜Ｇｌｙｐｈｓ＞タグがあればステップ５０３へ戻り、フォントデータからの文字送り幅とオフセットの算出処理を繰り返す。一方、ＸＰＳデータ内で見つかったすべての＜Ｇｌｙｐｈｓ＞タグが処理済みであれば、ステップ５０５へ進む。

ステップ５０５では、画像処理部３０２において、ＸＰＳデータにおいて描画が指示された各オブジェクトのラスタライズがなされる。そして、フォントを使用したテキスト属性のオブジェクトについては、フォント処理部２０６を介して、フォントラスタライザ２０７によって文字フォントのラスタライズがなされることになる。この際、ステップ５０３で算出したフォント文字送り幅とオフセットの各値における小数点以下に対し、所定の丸め処理を行なって得られた値を用いることで、印刷出力されるバーコードにおいて適切なスペース幅が実現される。本実施形態における所定の丸め処理は、具体的には、フォント文字送り幅に対しては「小数点以下を四捨五入」、オフセット値に対しては「小数点以下を切り捨て」である。そして、これら丸め処理後のフォント文字送り幅とオフセットの各値を加算して得られた合計値が、スペース幅となる。この丸め処理を行って得られた結果が、図８の行８０５の「フォント（丸め）」に記載されている。図８の行８０５に記載の各値と行８０１に記載の各値とを比較すると、全ての値が一致していることがわかる。これにより、ＭＸＤＣ２０２を介したＸＰＳプリントパスにおいてもバーコードフォントのスペース幅が、ＧＤＩプリントパスにおけるスペース幅と一致することになる。

以上が、本実施形態に係る、バーコードフォントを用いたテキスト属性のオブジェクトのレンダリング処理の内容である。なお、上述のフローでは、フォントを用いたテキスト属性のオブジェクトの描画についてはすべてフォントデータから算出した文字送り幅が使用されることになる。しかし、バーコードフォントでは、バーの太さやバー間隔が厳密に再現することが要求されるが、通常の文字の描画では、文字送り幅の精度がそれほど要求されないこともある。そこで、入力されたＸＰＳデータ内のバーコードフォントが使用されているオブジェクトに対してのみ、フォントデータからの文字送り幅の算出を行うようにしてもよい。バーコードフォントを使用しているかどうかは、例えば、プリレンダリングしてバーコードのビットマップが印刷データの中にあるかを調べることで判別可能である。あるいは、ＸＰＳデータに記載されたフォント情報やバーコード種別が、ＯＳに登録されているバーコードフォントと一致するかを確認してもよい。また、ＰＣ１０のＵＩ（ユーザインタフェース）を介して、バーコードフォントを使用する印刷モード（バーコード印刷モード）が指定された場合にのみ、図５のフローが実行されるように構成してもよい。

＜変形例１＞
上述した手法は、例えば図９（ａ）に示すように、バーコードフォントを用いて描画される２つのバーコード９０１と９０２がページ内の同じＸ座標上に存在している場合には適用できない。図９（ｂ）は、２つのバーコード９０１と９０２が空白９０３を挟んで同一Ｘ座標上に存在するページのＸＰＳデータである。このＸＰＳデータでは、１つの＜Ｇｌｙｐｈｓ＞タグ内に、２つのバーコード９０１と９０２に対応して、それぞれのバーコードを構成する単位文字のＧｉｄの番号と各文字についての文字送り幅の情報が記載される。そして、Ｉｎｄｉｃｅｓにおいて、空白９０３に相当する文字送り幅の情報（要素）９０４も記載される。すなわち、この場合の要素９０４が表す文字送り幅は１つのバーコード内のバーの間隔を表す文字送り幅ではない。このような空白は、ユーザが意図的に設ける場合や、アプリケーションによって自動的に挿入される場合などがある。いずれの場合においても、このような意図的な空白部分を表す文字送り幅にまで上述の手法を適用すると、意図された空白とは異なる幅の空白になってしまう。

そこで、Ｉｎｄｉｃｅｓに記載された文字送り幅が「２つのバーコード間の空白を示す送り幅」である場合には、本実施形態の手法を適用しないようにする態様を変形例として説明する。

図１０は、本変形例に係る、適切な文字送り幅を確保する処理の詳細を示すフローチャートである。本フローは、図５のフローにおけるステップ５０３に対応している。本変形例の適用にあっては、図５のフローの各ステップのうちステップ５０３以外のステップについては変更の必要はないため、それらの説明を省く。以下、図９（ｂ）のＸＰＳデータが入力されたものとして、図１０のフローに沿って、本変形例における処理内容を説明する。

ステップ１００１では、図９（ｂ）のＸＰＳデータから、描画対象の文字についてのＸＰＳ文字送り幅が抽出される。Ｇｉｄの番号“91”で特定される文字（空白９０３の直前に描画される文字）が描画対象の文字である場合、要素９０４の値“2604”が、ＸＰＳ文字送り幅として抽出される。

続くステップ１００２では、前述の表１に示すフォントデータから、描画対象の文字についてのフォント文字送り幅が抽出される。その抽出方法は、ステップ５０３で説明したとおりである。ここでは、前述の式（４）から、520 * (100/1000) * (160/100) * 0.115026 * (600/96) = 59.81352（px）が、フォント文字送り幅として算出されることになる。なお、フォント送り幅の算出時には、前述のとおりオフセットも同時に算出されるが、ここでは省略する。

ステップ１００３では、ステップ１００１で抽出されたＸＰＳ文字送り幅とステップ１００２で抽出されたフォント文字送り幅とが比較される。両者を比較した結果、その差分の絶対値が所定値以上の非常に大きな値である場合は、描画対象の文字についての文字送り幅は、空白９０３のような意図的に設けられた文字間の空白と判断する。ここで、「差分の絶対値が非常に大きい」かどうかの判別は、フォントデータ内にある全てのＧｉｄで特定される文字についての文字送り幅の最大値よりも大きい、或いは、最小値よりも小さいことを条件とすることが一例として挙げられる。得られた差分の絶対値が非常に大きいとはいえない場合は、描画対象の文字についての文字送り幅は意図的な空白ではないと判断する。このようにして、本実施形態の手法を適用すべきか否かを判断し、判断結果に応じて処理の切り分けを行う。具体的には、ＸＰＳ送り幅とフォント送り幅との差分の絶対値が非常に大きく、当該文字送り幅は意図的に設けられた文字間の空白と判断された場合にのみ、ステップ１００４に進む。そして、意図的な空白とは判断されない場合は、本処理を抜ける。

ステップ１００４では、適切な文字送り幅としてＸＰＳ文字送り幅を採用して、次の描画対象となる文字の文字開始位置が決定される。この場合において、意図された空白の直後に描画される文字についての文字開始位置は、そこまでの文字（同一Ｘ座標上において既に描画された文字）の文字送り幅の合計値から求めることができる。例えば、意図的な空白直後の文字が＜Ｇｌｙｐｈｓ＞タグ内で１０番目の文字であったとすると、＜Ｇｌｙｐｈｓ＞の開始座標を起点として、１〜９番目の各文字についてのＸＰＳ文字送り幅の合計値を、次の描画対象の文字の開始座標とする。これは、ＸＰＳデータに記載されている文字送り幅は、相対座標には揺らぎがあるものの絶対座標は正確であると考えられることから、意図的な空白の直後に描画される文字の開始位置は、それらの値を使用して決定した方がより正確になるためである。

以上が、本変形例に係る、文字送り幅の種類を判別して、適切な文字送り幅を確保する処理の内容である。このように本変形例の手法によれば、ＸＰＳデータに記載された文字送り幅がユーザやアプリケーションによって意図的に設けられた空白を表している場合には、上述の実施形態の手法の適用が回避され、適切な文字送り幅が確保される。その結果、バーコードを構成する単位文字の描画時には正確な文字送り幅を担保しつつ、意図的な空白については意図されたスペース幅で描画することが可能となる。

以上のとおり本実施形態では、フォントデータから算出した文字送り幅に基づいてバーコードフォントのレンダンリングを行う。これにより、ＭＸＤＣからのＸＰＳデータに従って、フォントを用いたバーコード印刷用のＰＤＬデータをＶ４ドライバで生成する場合であっても、適切なバー間隔のバーコードを印刷することが可能となる。こうして印刷されたバーコードにおいてはバー間隔が理論値に近くなっているので、バーコードを正確に読み取ることができる。

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

Claims (14)

1. アプリケーションから入力されたＧＤＩ形式の描画データをＸＰＳ形式の描画データに変換する変換手段と、
   前記ＸＰＳ形式の描画データをレンダリングしてＰＤＬデータに変換するレンダリング手段と、
   を備え、
   前記レンダリング手段は、前記ＸＰＳ形式の描画データ内の描画対象のオブジェクトが、フォントを用いて描画するテキスト属性の文字オブジェクトである場合、フォントデータから算出した文字送り幅に基づいてレンダリングする
   ことを特徴とする情報処理装置。
2. 前記レンダリング手段は、前記文字オブジェクトについて、前記フォントデータに含まれる文字送り幅の情報から、デバイス解像度における文字送り幅を算出する、ことを特徴とする請求項１に記載の情報処理装置。
3. 前記フォントは、バーコードフォントであることを特徴とする請求項２に記載の情報処理装置。
4. 印刷モードを指定できるユーザインタフェースをさらに備え、
   前記レンダリング手段は、前記ユーザインタフェースを介して、前記バーコードフォントを使用する印刷モードが指定されている場合に、前記文字オブジェクトについて、フォントデータから算出した文字送り幅に基づいてレンダリングする
   ことを特徴とする請求項３に記載の情報処理装置。
5. 前記ＸＰＳ形式の描画データ内に、前記バーコードフォントを用いて描画する文字オブジェクトが存在するかどうかを判定する判定手段をさらに備えたことを特徴とする請求項４に記載の情報処理装置。
6. 前記判定手段は、
   プリレンダリングを行なう手段を有し、
   前記プリレンダリングの結果、バーコードのビットマップがある場合に、前記バーコードフォントを用いて描画する文字オブジェクトが存在すると判定する
   ことを特徴とする請求項５に記載の情報処理装置。
7. 前記判定手段は、前記ＸＰＳ形式の描画データ内のフォント情報又はバーコード種別が、ＯＳに登録されているバーコードフォントと一致する場合に、前記バーコードフォントを用いて描画する文字オブジェクトが存在すると判定する、ことを特徴とする請求項５に記載の情報処理装置。
8. 前記レンダリング手段は、
   前記フォントデータに含まれる文字送り幅の情報から算出した前記デバイス解像度における文字送り幅に対して、第一の丸め処理を行って整数値にし、
   前記フォントデータから、文字開始位置から描画開始位置までの距離を示すオフセット値を算出し、当該算出したオフセット値に対して第二の丸め処理を行って整数値にし、
   前記丸め処理後の文字送り幅とオフセット値とを足し合わせた値で特定される位置に基づいて、次の描画対象の文字オブジェクトをレンダリングする
   ことを特徴とする請求項２乃至７のいずれか１項に記載の情報処理装置。
9. 前記第一の丸め処理は、小数点以下の四捨五入であり、
   前記第二の丸め処理は、小数点以下の切り捨てである、
   ことを特徴とする請求項８に記載の情報処理装置。
10. 前記レンダリング手段は、前記ＸＰＳ形式の描画データに含まれる文字送り幅の情報から、前記デバイス解像度における文字送り幅を算出し、当該算出した文字送り幅と、前記フォントデータに含まれる文字送り幅の情報から算出した前記デバイス解像度における文字送り幅との差分の絶対値が所定の条件を満たす場合には、前記ＸＰＳデータから算出した文字送り幅に基づいて、次の描画対象の文字オブジェクトをレンダリングすることを特徴とする請求項２乃至７のいずれか１項に記載の情報処理装置。
11. 前記レンダリング手段は、前記差分の絶対値が、前記フォントデータ内にある全てのＧｉｄで特定される文字についての文字送り幅の最大値よりも大きい、或いは、最小値よりも小さい場合に、前記所定の条件を満たすと判断する、ことを特徴とする請求項１０に記載の情報処理装置。
12. 変換手段が、アプリケーションから入力されたＧＤＩ形式の描画データをＸＰＳ形式の描画データに変換するステップと、
    レンダリング手段が、前記ＸＰＳ形式の描画データをレンダリングしてＰＤＬデータに変換するレンダリングステップと、
    を含み、
    前記レンダリングステップでは、前記ＸＰＳ形式の描画データ内の描画対象のオブジェクトが、フォントを用いて描画するテキスト属性の文字オブジェクトである場合、フォントデータから算出した文字送り幅に基づいてレンダリングする
    ことを特徴とする情報処理方法。
13. ＧＤＩ形式からＸＰＳ形式に変換された描画データをレンダリングして、ＰＤＬデータを生成するプリンタドライバであって、
    前記ＸＰＳ形式の描画データ内の描画対象のオブジェクトが、フォントを用いて描画するテキスト属性の文字オブジェクトである場合、フォントデータから算出した文字送り幅に基づいてレンダリングする
    ことを特徴とするプリンタドライバ。
14. コンピュータを、請求項１乃至１１のいずれか１項に記載の情報処理装置として機能させるためのプログラム。

Images