(57)【要約】【課題】  変形時の文字画像の品位の劣化を極力抑えつつ、より高速な方法で文字描画を行うことを目的とする。【解決手段】  フォントデータから文字の形状情報である第１の形状情報を取得し、文字を描画する際に用いる描画文字サイズを取得し、第１の形状情報と、描画文字サイズに基づいて、第２の形状情報を生成し、第２の形状情報を、前記フォントデータと対応付けて格納する。【選択図】  図５
2014202939.tif 000002
【特許請求の範囲】
【請求項１】
フォントデータから文字の形状情報である第１の形状情報を取得する第１の取得手段と、
文字を描画する際に用いる描画文字サイズを取得する第２の取得手段と、
前記第１の形状情報と前記描画文字サイズに基づいて、第２の形状情報を生成する生成手段と、
前記第２の形状情報を、前記フォントデータと対応つけて格納する格納手段を有することを特徴とする描画処理装置。
【請求項２】
前記第２の形状情報に基づいて、前記文字の描画を行う描画手段を有することを特徴とする請求項１に記載の描画処理装置。
【請求項３】
前記生成手段は、前記第１の形状情報を、前記描画文字サイズと同じ大きさに拡大または縮小することにより、前記第２の形状情報を生成することを特徴とする請求項１又は請求項２に記載の描画処理装置。
【請求項４】
前記第２の取得手段が複数種類の描画文字サイズを取得したかを判定する判定手段と、
前記判定手段の判定で、複数種類の描画文字サイズを取得したと判定された場合、前記生成手段は、前記複数種類の描画文字サイズのうち、最大の描画文字サイズと、前記第１の形状情報に基づいて、第２の形状情報を生成することを特徴とする請求項１又は請求項２に記載の描画処理装置。
【請求項５】
前記第２の取得手段が１種類の描画文字サイズを取得したか、複数種類の描画文字サイズを取得したかを判定する判定手段と
前記判定手段の判定で、１種類の描画文字サイズを取得したと判定された場合、前記生成手段は、前記第１の形状情報と前記描画文字サイズに基づいて、第２の形状情報を生成し、
前記判定手段の判定で、複数種類の描画文字サイズを取得したと判定された場合、前記生成手段は、前記複数種類の描画文字サイズのうち、最大の描画文字サイズと、前記第１の形状情報に基づいて、第２の形状情報を生成することを特徴とする請求項１又は請求項２に記載の描画処理装置。
【請求項６】
描画処理装置の制御方法であって、
第１の取得手段が、フォントデータから文字の形状情報である第１の形状情報を取得する第１の取得工程と、
第２の取得手段が、文字を描画する際に用いる描画文字サイズを取得する第２の取得工程と、
生成手段が、前記第１の形状情報と、前記描画文字サイズに基づいて、第２の形状情報を生成する生成工程と、
格納手段が、前記第２の形状情報を、前記フォントデータと対応つけて格納する格納工程を有することを特徴とする描画処理装置の制御方法。
【請求項７】
描画手段が、前記第２の形状情報に基づいて、前記文字の描画を行う描画工程を有することを特徴とする請求項５に記載の描画処理装置の制御方法。
【請求項８】
前記生成工程は、前記第１の形状情報を、前記描画文字サイズと同じ大きさに拡大または縮小することにより、前記第２の形状情報を生成することを特徴とする請求項６又は請求項７に記載の描画処理装置の制御方法。
【請求項９】
判定手段が、前記第２の取得工程で複数種類の描画文字サイズを取得したかを判定する判定工程と、
前記判定工程で、複数種類の描画文字サイズを取得したと判定された場合、前記生成工程は、前記複数種類の描画文字サイズのうち、最大の描画文字サイズと、前記第１の形状情報に基づいて、第２の形状情報を生成することを特徴とする請求項６又は請求項７に記載の描画処理装置の制御方法。
【請求項１０】
判定手段が、前記第２の取得工程で１種類の描画文字サイズを取得したか、複数種類の描画文字サイズを取得したかを判定する判定工程と
前記判定工程で、１種類の描画文字サイズを取得したと判定された場合、前記生成工程は、前記第１の形状情報と前記描画文字サイズに基づいて、第２の形状情報を生成し、
前記判定工程で、複数種類の描画文字サイズを取得したと判定された場合、前記生成工程は、前記複数種類の描画文字サイズのうち、最大の描画文字サイズと、前記第１の形状情報に基づいて、第２の形状情報を生成することを特徴とする請求項６又は請求項７に記載の描画処理装置の制御方法。
【請求項１１】
コンピュータを、請求項１乃至５の何れか１項に記載の描画処理装置が有する各手段として機能させるためのプログラム。
【請求項１２】
請求項１１に記載のプログラムを格納した、コンピュータが読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、文字の描画処理に関する。
【背景技術】
【０００２】
従来、アウトラインフォント等のベクトル形式で記述されたフォントデータを描画する際には、レンダリングした後のビットマップ画像やレンダリング途上の情報をメモリに格納し、キャッシュデータとして再利用する技術がある。例えば、アウトラインフォントをスキャンライン処理して作成した中間データを記憶手段に格納し、文字の再描画を行う際に中間データを使用し高速に描画する方法があった（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−７１８６２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、ビットマップ画像をキャッシュする方法では、文字の拡大等の変形を行うと、画質が著しく劣化するという課題があった。また、スキャンライン処理により作成した中間データを格納する方法においても、文字の拡大等の変形を行うと画質が劣化するという課題があった。一方、アウトラインデータまたはベクトルデータ自体をキャッシュすれば変形時の画質の劣化は避けられるが、レンダリング処理に時間がかかるという課題があった。
【０００５】
そこで本発明では、変形時の文字画像の品位の劣化を極力抑えつつ、より高速な方法で文字描画を行うことを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明に係る描画処理装置は、フォントデータから文字の形状情報である第１の形状情報を取得する第１の取得手段と、文字を描画する際に用いる描画文字サイズを取得する第２の取得手段と、前記第１の形状情報と、前記描画文字サイズに基づいて、第２の形状情報を生成する生成手段と、前記第２の形状情報を、前記フォントデータと対応つけて格納する格納手段を有する。
【発明の効果】
【０００７】
本発明により、変形時の文字画像の品位の劣化を極力抑えつつ、より高速な方法で文字描画を行うことができる。
【図面の簡単な説明】
【０００８】
【図１】本実施形態の描画処理装置の構成を示すブロック図。
【図２】本実施形態の描画処理装置の機能ブロック図。
【図３】フォントデータに含まれている文字の形状の例を示した図。
【図４】関連情報テーブルの一例。
【図５】本実施形態における描画処理装置のフローチャート。
【図６】Ｓ５１５の詳細フローチャート。
【図７】文字の形状情報を管理するテーブルの例。
【図８】文字形状情報の、格納サイズに対する一つの座標値の使用ビット数を示したテーブルの例。
【図９】Ｓ５０７の詳細フローチャート。
【図１０】関連情報テーブルに変更があった場合の描画処理装置のフローチャート。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について、図面を参照して説明する。なお、以下の実施の形態は特許請求の範囲に関る本発明を限定するものではなく、また、本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一な構成については、同じ符号を付して説明する。
【００１０】
図１は本実施形態の描画処理装置の構成を示すブロック図である。
【００１１】
図１において、ＣＰＵ１０１はシステム制御部であり装置全体を制御する。ＲＯＭ１０２は、ＣＰＵ１０１の制御プログラムや各種固定データを格納する読取専用のメモリである。ＲＡＭ１０３は、ＳＲＡＭ、ＤＲＡＭ等で構成された書換え可能なメモリであり、プログラム制御変数等を格納するためのものである。各種設定パラメータ、各種ワーク用バッファ等もＲＡＭ１０３に格納されるものである。表示部１０４は、ＬＣＤ等を用いて文字や画像等のグラフィックスを表示するためのものである。操作部１０５は、キーボードやポインティングデバイス等で構成され、オペレータが各種入力操作を行うためのものである。１０６は１０１〜１０５の各ユニットを通信可能に接続するシステムバスである。
【００１２】
図２は、本実施形態の描画処理装置における文字列描画機能のモジュール構成を示した図である。
【００１３】
図２において、第１の取得部２０１は、ＲＯＭ１０２に格納されているフォントデータから文字の形状情報（第１の形状情報）を取得する。ここで、文字の形状情報とは、文字のアウトラインを示す座標群や文字の幅と高さを含む情報である。生成部２０２は、文字の形状情報のサイズを変更して、第２の形状情報を生成する。例えば、日本語全角文字は、２０４８×２０４８や１０２４×１０２４のメッシュサイズで形状情報が定義されており、これを１２８×１２８などのメッシュサイズによる定義に変更して、第２の形状情報を生成する。
【００１４】
格納部２０３は、生成部２０２が生成した第２の形状情報を、フォントデータと関連付けてＲＡＭ１０３に格納する。第１の取得部２０１が取得した形状情報を生成部２０２が変更せずに、格納部２０３が格納するケースもあり得る。また、格納部２０３は、文字が使用される使用場面情報と、フォントデータ、文字描画サイズを関連付けた情報も格納する。描画部２０４は、格納部２０３が格納した形状情報に基づいて、文字の描画を行う。第２の取得部２０５は、その文字が使用される場面や状況を特定し、その文字が描画される際の描画文字サイズを取得する。
【００１５】
変更部２０６は、オペレータが操作部１０５を操作することによって、ＲＡＭ１０３に格納されている関連情報を変更する。解析部２０７は、ＨＴＭＬやＣＳＳなどで記述された描画コンテンツを解析する手段であり、コンテンツに含まれる文字が使用するフォントデータや描画文字サイズを取得することができる。
【００１６】
図３は、フォントデータに含まれている文字の形状の例を示した図である。図３に示した文字「あ」は、文字のアウトラインを構成する座標がすべて２０４８×２０４８の座標の範囲で定義されている。この２０４８×２０４８をメッシュサイズと呼び、アウトラインを構成する各座標は０〜２０４７の整数値で定義されている。一般に流通している日本語フォントデータは、１０００×１０００や１０２４×１０２４、２０４８×２０４８等のメッシュサイズで定義されていることが多い。フォントフォーマットによって異なるが、アウトラインデータは、２次ベジェ曲線や３次ベジェ曲線、線分等で構成されている。いずれのフォーマットであっても、１文字のアウトラインを示すために、複数の点の座標を含んでいる。本実施形態ではアウトラインフォントを用いているが、文字の字画の中心線をベクトルデータで定義したストロークフォントを用いても良い。
【００１７】
図４（ａ）は、文字の使用場面と使用フォント名、その使用場面における描画文字サイズを関連付けた関連情報テーブルの一例である。本実施形態における描画処理装置では、図４（ａ）に示した関連情報テーブルをＲＡＭ１０３に格納している。例えば、図４（ａ）に示した表の２行目は、ユーザインタフェースのメニュー画面においては、「ｆｏｎｔ１」という名前のフォントを使用し、その際の描画文字サイズは４０であることを示している。一つの使用場面に対し、複数の描画文字サイズが使用されることもあり得る。ここでは描画文字サイズの単位はピクセルであるが、ポイントやミリメートル等でも良い。また、一つの使用場面に対し複数のフォント名を関連付け、その優先順位を付けるようにしても良い。例えば、日本語表示用フォントデータ、英語表示用フォントデータ、中国語表示用フォントデータをそれぞれ別にＲＯＭ１０２に持っている場合、複数のフォント名が関連付けられる。その場合、文字列中のある文字を描画しようとする際に、関連情報テーブル内に格納された優先順位に従って処理が行われる。例えば、まずその文字が日本語表示用フォントデータに存在するかを検索し、存在しなければ、次に英語表示用フォントデータに存在するかを検索する、ということを行う。また、図４（ａ）においては、ＨＴＭＬ等で記述されたコンテンツのブラウザは、コンテンツ中に指定された描画文字サイズで描画を行うため、描画文字サイズが不定となっている。
【００１８】
図５は、本実施形態における描画処理装置の文字列描画時の動作を示したフローチャートである。同図に示したとおり、まず、第１の取得部２０１が、文字数カウンタの変数Ｎに０をセットする（Ｓ５０１）。次に、第１の取得部２０１が、文字列中のＮ文字目の文字の形状情報がＲＡＭ１０３に格納されているか否かを判定する（Ｓ５０２）。装置が起動後の最初の処理では、ＲＡＭ１０３に格納されている形状情報はないが、いったん図５の処理を行った後では、ＲＡＭ１０３にその文字の形状情報が格納されている可能性がある。Ｓ５０２で既にＲＡＭ１０３にその文字の形状情報が格納されていると判定されれば、改めて形状情報を格納する必要はないので、Ｓ５１３の処理に進む。
【００１９】
Ｓ５０２でその文字の形状情報が格納されていないと判定されれば、第１の取得部２０１が、フォントデータから形状情報を取得する（Ｓ５０３）。Ｓ５０３では、描画しようとする文字とこの処理が行われている場面と関連情報テーブルに基づいてフォントデータからその文字の形状情報を取得する。このとき取得した形状情報は、フォントデータで定義されたメッシュサイズに従った情報である。続いて、第２の取得部２０５が、関連情報テーブルに基づいて、描画文字サイズを取得する（Ｓ５０４）。例えば、現在の処理が行われている場面がメニュー画面とすると、図４（ａ）に示した関連情報テーブルから、使用するフォントデータは「ｆｏｎｔ１」であることが判定できる。さらに、「ｆｏｎｔ１」が使用される場面の描画文字サイズは、メニュー画面が４０であり、アイコン名表示は２４であることが判定できる。すなわち、現在描画仕様とする文字が使用される可能性のある場面の描画文字サイズは２４と４０であることがわかる。Ｓ５０４では、これら、４０、２４等の使用される可能性のある描画文字サイズをすべて取得するものである。Ｓ５０４においては、関連情報テーブルに基づいて描画文字サイズを取得するだけでなく、ＨＴＭＬ等で記述されたコンテンツを描画するケースでは、ＨＴＭＬ文書を解析して、描画文字サイズを取得する場合もある。ＨＴＭＬやＣＳＳを用いたＷｅｂ文書では、コンテンツ中にフォント名や描画文字サイズを指定することができる。その場合、あるＷｅｂページを描画する際、そのページ全体を解析し、そのページで使用されるフォント名と描画文字サイズを取得する。
【００２０】
続いて、Ｓ５０５において、生成部２０２が、描画文字サイズが１種類か、複数種類かを判定する。ここで描画文字サイズが１種類と判定されれば、生成部２０２が、その文字の第１の形状情報を描画文字サイズに変更して、第２の形状情報を生成し（Ｓ５０６）、格納部２０３が、ＲＡＭ１０３に格納する（Ｓ５１２）。Ｓ５０６では、フォントデータのメッシュサイズと描画文字サイズの大小関係によっては、縮小されることも、拡大されることもあり得る。後述するが、Ｓ５０６で、第１の形状情報を描画文字サイズにリサイズ（縮小または拡大）して、第２の形状情報を生成することにより、描画時の拡大縮小処理を軽減することができる。
【００２１】
Ｓ５０５において、描画文字サイズが複数種類と判定されれば、生成部２０２が、最大の描画文字サイズに基づいて、第２の形状情報を生成し（Ｓ５０７）、格納部２０３が、ＲＡＭ１０３に格納する（Ｓ５１２）。
【００２２】
Ｓ５１２で第２の形状情報をＲＡＭ１０３に格納した後は、描画部２０４が、文字数カウンタの変数Ｎに１を加え（Ｓ５１３）、描画部２０４が、描画しようとする文字列にＮ文字目が存在するか否かを判定する（Ｓ５１４）。ここで、Ｎ文字目が存在すると判定されれば、Ｓ５０２以降の処理を繰り返す。Ｓ５１４でＮ文字目が存在しないと判定されれば、描画しようとする文字列中の文字の形状情報はすべてＲＡＭ１０３に格納されていることになるから、描画部２０４が、その文字列を描画し（Ｓ５１５）、処理を終了する。
【００２３】
図９は、Ｓ５０７の詳細フローチャートである。
【００２４】
生成部２０２が、最大の描画文字サイズが６４以下か否かを判定する（Ｓ９０７）。ここで最大の描画文字サイズが６４以下と判定されれば、生成部２０２が、その文字の形状情報を描画文字サイズ６４にリサイズして、第２の形状情報を生成する（Ｓ９０８）。Ｓ９０７において、最大の描画文字サイズが６４以下ではないと判定されれば、生成部２０２が、最大の描画文字サイズが１２８以下か否かを判定する（Ｓ９０９）。ここで最大の描画文字サイズが１２８以下と判定されれば、生成部２０２が、その文字の形状情報を描画文字サイズ１２８にリサイズして、第２の形状情報を生成する（Ｓ９１０）
Ｓ９０９において、最大の描画文字サイズが１２８以下ではないと判定されれば、生成部２０２が、その文字の形状情報を描画文字サイズ２５６にリサイズして、第２の形状情報を生成する（Ｓ９１１）。関連情報テーブルに描画文字サイズが不定と記述されているフォントの場合も、Ｓ５０５、Ｓ９０７、Ｓ９０９の分岐を経て、Ｓ９１１で描画文字サイズ２５６にリサイズされる。Ｓ９１１では描画文字サイズ２５６にリサイズしているが、リサイズせずにフォントデータのメッシュサイズのままＲＡＭ１０３に格納しても良い。一般のユーザインタフェースでは文字の描画文字サイズは２５６以下であることが多いため、本実施形態では、描画文字サイズ２５６にリサイズしている。
【００２５】
図６は、Ｓ５１５の詳細フローチャートである。同図に示したとおり、まず、描画部２０４が、描画しようとする文字列の文字数カウンタ変数Ｎに０をセットする（Ｓ６０１）。
【００２６】
次に、描画部２０４は、描画しようとする文字列のＮ番目の文字の格納サイズが、現在の使用場面の描画文字サイズと一致しているか否かを判定する（Ｓ６０２）。ここで、ＲＡＭ１０３に格納されている第２の形状情報のサイズと描画文字サイズとが一致していると判定されれば、描画部２０４は、そのサイズで描画を行う（Ｓ６０３）。一致していないと判定されれば、描画部２０４が、描画文字サイズにスケーリング（拡大または縮小）して描画を行う（Ｓ６０４）。Ｓ６０４においては、ほとんどの場合は縮小処理になるが、Ｓ５１１を通るような文字のケースでは、拡大処理となることもある。
【００２７】
Ｓ６０３またはＳ６０４の処理に続いて、描画部２０４が、文字数カウンタ変数Ｎに１を加え（Ｓ６０５）、描画しようとする文字列にＮ文字目が存在するか否かを判定する（Ｓ６０６）。Ｓ６０６において、Ｎ文字目が存在すると判定されれば、Ｓ６０２以降の処理を繰り返す。Ｎ文字目が存在しないと判定されれば、文字列中のすべての文字の描画が行われたことになるから、処理を終了する。
【００２８】
図７は、文字の形状情報を管理するテーブルの例である。このテーブルもＲＡＭ１０３に格納され、文字の形状情報が追加や削除されるたびに更新される。図７に示した通り、フォント名情報ごとに文字形状情報の格納サイズと格納文字数、格納された形状情報の配列の先頭アドレスを保持している。本実施形態では、一つのフォントに対し格納サイズを１種類としているが、使用される個々の文字の描画サイズを解析し、文字ごとに異なる格納サイズにしても良い。
【００２９】
図８は、文字形状情報の、格納サイズに対する一つの座標値の使用ビット数を示したテーブルである。このテーブルもＲＡＭ１０３に格納される。格納サイズが６４の場合は各座標値の値は０〜６３の整数値となり、その座標値の表現に必要なビット数は６ビットである。同様に、図８に示した通り、格納サイズが１２８のときには７ビット、２５６のときには８ビットとなる。本実施形態では格納サイズが２５７以上となるのは例外的な場合なので、１６ビットを使用して格納する。このように、格納サイズを小さくすることにより、座標値を表現するビット数を減らすことができ、ＲＡＭ１０３の使用量を減らせる。すなわちメモリ使用量低減の効果がある。一方で、座標の精度は低くなるため、文字の描画結果の品位は若干低下する。ただし、Ｓ５０９及び、図９で説明したように最大描画文字サイズに合わせて格納サイズを決定しているため、描画品位の低下は極力少なくなっている。
【００３０】
また、格納サイズを６４、１２８、２５６など、２の累乗の値にしているのは、Ｓ６０４で再度縮小（または拡大）する際の計算量を減らすためである。座標値が正の値であり、かつ、格納サイズが２の累乗であれば、縮小または拡大するときの演算で除算を回避可能である。例えば、格納サイズがＺであるアウトラインデータのある点のＸ座標が１０だとすると、その文字を描画サイズ３０にスケーリングした場合の新たなＸ座標の計算式は、１０×３０／Ｚとなる。Ｚが２の累乗であれば、ビットシフト演算で計算ができる。すなわち、格納サイズが６４であれば、６シフトすれば良い。一般に除算よりもビットシフトの方が計算量が少なく高速に処理できるため、本実施形態では格納サイズを２の累乗の値にしている。
【００３１】
図４（ｂ）は、図４（ａ）に示した関連情報テーブルが、操作部１０５を介してオペレータにより変更された後の状態を示した図である。同図に示した通り、（＊）で示した項目、すなわち、メニュー画面の文字サイズとメール本文のフォント名が変更になっている。
【００３２】
図１０は、関連情報テーブルに変更があった場合の処理を示したフローチャートである。同図に示した通り、まず、変更部２０６は、フォント数のカウンタ変数Ｍに０をセットする（Ｓ１００１）。ここでフォント数とは、ＲＡＭ１０３に格納された文字に対応するフォントの個数である。図７に示したテーブルの例では、フォント数は４個である。
【００３３】
続いて、変更部２０６は、図７のテーブル中のＭ番目のフォントの格納サイズに変更があったか否かを判定する（Ｓ１００２）。ここで、変更部２０６は、変更があったと判定されれば、Ｍ番目のフォントに関連した文字形状情報をＲＡＭ１０３から破棄する（Ｓ１００３）。Ｓ１００２でＭ番目のフォントの格納サイズに変更がなかったと判定されれば、次のフォントの処理を行うためＳ１００４の処理へ移行する。
【００３４】
変更部２０６は、Ｓ１００４で変数Ｍに１を加え、Ｍ番目のフォントが存在するか否かを判定する（Ｓ１００５）。Ｍ番目のフォントが存在すると判定されれば、Ｓ１００２以降の処理を繰り返す。Ｓ１００５でＭ番目のフォントが存在しないと判定されれば、図７に示したテーブルのすべてのフォントの処理が終わったことになるため、処理を終了する。このような処理を行うことにより、不要になった文字やサイズが変わった文字の形状情報をＲＡＭ１０３から破棄することができる。
【００３５】
なお、本実施形態では、描画処理装置を例に説明したが、本発明は、印刷装置、デジタルカメラ、複写機、複合機、スキャナ、テレビ等、表示部や印字部を有するあらゆる装置に適用可能である。本発明はソフトウエアにより実現しても良い。すなわち、ソフトウエアのプログラムコードを記録した記録媒体をシステムあるいは装置に供給し、そのシステムあるいは装置のＣＰＵが記録媒体に格納されたプログラムコードを読み出し実行することで実現しても良い。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、磁気テープ、メモリカードなどを用いることができる。また、本発明は、プログラムコードの指示に基づき、コンピュータ上で稼動しているオペレーティングシステムなどが実際の処理の一部または全部を行い、その処理によって機能が実現される場合にも適用され得る。
【図１】
2014202939.tif 000003
【図２】
2014202939.tif 000004
【図３】
2014202939.tif 000005
【図４】
2014202939.tif 000006
【図５】
2014202939.tif 000007
【図６】
2014202939.tif 000008
【図７】
2014202939.tif 000009
【図８】
2014202939.tif 000010
【図９】
2014202939.tif 000011
【図１０】
2014202939.tif 000012