(57)【要約】      （修正有）【課題】エンジン解像度の変更に対応し、外字Fontのimageを適切に編集して外字印刷を行ない、ユーザ資産の活用が可能となる画像処理装置を提供する。【解決手段】ページバッファ、エンジン、文字コードに対応するフォントイメージを一時的にキャッシュするフォントキャッシュメモリ、受信バッファ、フォントが入っているフォントＲＯＭ１１及びＨＤＤ１２、文字生成部、文字管理部、制御部から構成される画像処理装置である。文字コードは第一水準に含まれているが、字形を変えてみたい場合に、ＨＤＤ１２上段の形式で外字登録する。ＨＤＤ１２上段のFont Fileは、Font SetID １、Style Ｇとなる。また、文字コードを外字領域に定義した場合（Font SetID Ｇ）、ＨＤＤ１２下段の形式で登録する（Font SetID Ｇ、Style Ｇ）。【選択図】図２
2007245659.tif 000002
【特許請求の範囲】
【請求項１】
外字Fontを格納した外字Font Fileを記憶する外字記憶手段と、
標準搭載Fontを格納した標準Font Fileを記憶する標準記憶手段と、
印字すべき外字Fontを、前記標準搭載Fontと同様に指定されたサイズに変倍する変倍手段と、を備えることを特徴とする画像処理装置。
【請求項２】
前記外字Fontは、Bitmap Font形式で字形を作成したFontであり、
前記標準搭載Fontは、Outline Font形式であり、
前記変倍手段は、前記印字すべき外字FontがBitmap Fontならば、Bitmap Font変倍処理により前記標準搭載Fontと同様に指定されたサイズに変倍することを特徴とする請求項１記載の画像処理装置。
【請求項３】
前記外字Font File及び標準搭載Font Fileを、Font Headerによって識別し、サーチするサーチ手段を備えることを特徴とする請求項１又は２記載の画像処理装置。
【請求項４】
前記外字記憶手段は、使用頻度が高い外字Font含む外字Font Fileを、標準搭載Fontと同様の文字コードで作成し、標準搭載Font FileのFont並びと同様の並びで記憶することを特徴とする請求項１から３のいずれか１項に記載の画像処理装置。
【請求項５】
前記サーチを行なう際、標準記憶手段又は外字記憶手段のどちらからサーチするか順番を指定し、外字Font/標準Fontの切替えを行なう切替え手段を備えることを特徴とする請求項１から４のいずれか１項に記載の画像処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、画像処理装置に関し、特に外字書体の印刷を行なう画像処理装置に関する。
【背景技術】
【０００２】
従来から、オフィス等でプリンタや複合機等の画像処理装置が普及している。これに伴い印字の種類も多様化している。印字の高さや幅等を調整する技術や（例えば、特許文献１参照）、プリンタで素早い印字が出来るようフォント名称の置換対応表を備えるプリンタ（例えば、特許文献２参照）が提案されている。また、従来の標準搭載文字とは別に、外字印刷を搭載するプリンタ等の画像処理装置が知られている。外字印刷とは、標準搭載文字とは別にオリジナルの字形を定義したりユニークな文字コードを定義したりして、一般文書作成を行なうことである。
【０００３】
近年、外字を定義するにはホストＰＣ（Windows（登録商標）、特定アプリ）を利用することが圧倒的であるが、従来からの基幹系印刷では印刷機器に外字を搭載して使用しているケースが残っている。基幹系印刷の場合、印刷コマンドがユーザ自作であることが殆どである為に、無闇に変更出来ないことに起因している。
【特許文献１】特許第３５７４７１６号公報
【特許文献２】特開２０００−２６３８６０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、印刷機器自体の代替時にエンジン解像度が変更されたり、プリンタ言語が変更されたりする場合もある。一般に、印刷機器に外字を搭載する場合、Bitmap形式で表す。したがってエンジンの標準解像度が大きくなると、印字したときに外字部分だけ文字サイズが小さくなってしまう。
【０００５】
このため、ユーザ自らが過去の資産からBitmap形式の外字を持ち出してＰＣ上で変倍して外字登録する必要がある。しかし、外字Fontというimage（画像）を手動で変倍＆編集することは困難であり、元となる外字の意味を判っていないと間違えを犯す可能性を秘めている。
【０００６】
また、アウトラインフォント（Outline Font）で外字を作れば一番綺麗な印刷を期待できるが、一般ユーザに製作過程を開放するところは少ない上に、ユーザがアウトラインフォント製作技術に学習時間をかけてまで外字に重きをかけるか疑問であり、ユーザの資産であるBitmapで外字を扱えるのが望ましい。
【０００７】
また、文字の旁が違う場合、明朝・ゴシックのようにStyle変更では対応が出来ない。例えば、或る都市で戸籍を電子化するとき、「渡辺」という苗字を登録するのにImageの差異で分類すると４０通りの「渡辺」が存在し、それぞれ文字コードが異なるため、意識しないと使い分けられない。
【０００８】
本発明はこのような状況に鑑みてなされたものであり、エンジン解像度の変更に対応し、外字Fontのimageを適切に編集して外字印刷を行ない、ユーザ資産の活用が可能となる画像処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
請求項１記載の発明は、外字Fontを格納した外字Font Fileを記憶する外字記憶手段と、標準搭載Fontを格納した標準Font Fileを記憶する標準記憶手段と、印字すべき外字Fontを、前記標準搭載Fontと同様に指定されたサイズに変倍する変倍手段と、を備えることを特徴とする画像処理装置である。
【００１０】
請求項２記載の発明は、請求項１記載の装置において、前記外字Fontは、Bitmap Font形式で字形を作成したFontであり、前記標準搭載Fontは、Outline Font形式であり、前記変倍手段は、前記印字すべき外字FontがBitmap Fontならば、Bitmap Font変倍処理により前記標準搭載Fontと同様に指定されたサイズに変倍することを特徴とする。
【００１１】
請求項３記載の発明は、請求項１又は２記載の装置において、前記外字Font File及び標準搭載Font Fileを、Font Headerによって識別し、サーチするサーチ手段をさらに備えることを特徴とする。
【００１２】
請求項４記載の発明は、請求項１から３のいずれか１項に記載の装置において、前記外字記憶手段は、使用頻度が高い外字Font含む外字Font Fileを、標準搭載Fontと同様の文字コードで作成し、標準搭載Font FileのFont並びと同様の並びで記憶することを特徴とする。
【００１３】
請求項５記載の発明は、請求項１から４のいずれか１項に記載の装置において、前記サーチを行なう際、標準記憶手段又は外字記憶手段のどちらからサーチするか順番を指定し、外字Font/標準Fontの切替えを行なう切替え手段を備えることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、エンジン解像度の変更に対応し、外字Fontのimageを適切に編集して外字印刷を行ない、ユーザ資産の活用が可能となる画像処理装置を提供することが出来る。
【発明を実施するための最良の形態】
【００１５】
以下に、本発明の実施形態に係る画像処理装置を、図面を用いて詳細に説明する。なお、以下に述べる実施の形態は、本発明の好適な実施の形態であるから、技術的に好ましい種種の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの態様に限られるものではない。
【００１６】
図１は、本発明の実施形態に係る画像処理装置のブロック構成図である。複数の印刷データを一時的に蓄えておくページバッファ４、ページバッファ４に描画された印刷データを出力し印刷するエンジン３、文字コードに対応するフォントイメージを一時的にキャッシュしておくフォントキャッシュメモリ９、上位のホストＰＣ１から印刷コマンドを蓄えておく受信バッファ６、フォントが入っているフォントＲＯＭ１１及びＨＤＤ１２、フォントを印刷可能な輪郭イメージに変換する文字生成部１０、Bitmap fontやOutline fontの文字並び調整や斜体／ボールド体への変換などを実施する文字管理部８、制御部５から構成される。
【００１７】
ドキュメントはＥＳＣシーケンス（エスケープシーケンス）となってインターフェース部７経由で取り込まれる。その中で文字コードに該当する部分が抽出されて文字生成部１０に送られる。文字生成部１０は、文字コードに対応するフォントイメージをＨＤＤ１２又はフォントＲＯＭ１１から引用する。２つの媒体のどちらを先に選択して読み始めるかはUtilityやパネルにて切替えることが考え得る。
【００１８】
本実施形態に係るフォントＲＯＭ１１とＨＤＤ１２には、Font File（外字Font Fileや標準Font File）が記憶されている。フォントＲＯＭ１１は、標準搭載Font Fileを有している。基本的に必要なフォントとしてメーカが認めているフォント全てが入っている。一方、ＨＤＤ１２は、ユーザの意志で外字として登録したフォントが入っている。外字を登録する場合については後述する。
【００１９】
図２は、フォントＲＯＭ１１とＨＤＤ１２のフォントパーティションの構成を示す図である。フォントＲＯＭ１１にFont Fileを３つ以上、ＨＤＤ１２には２つのFont Fileを、例として示している。各Font FileのHeader（Font  Header）は、文字コード開始、文字コード終了、Style、Font SetＩＤ、Type（Font Type）、Scaleについて、識別子が付けられている。文字コード、Font SetＩＤ、Style、Typeの各分類について下記表に示す。
【００２０】
【表１】
2007245659.tif 000003
【００２１】
表１に示すように、文字コードはその範囲から非漢字・特殊文字・第一水準・第二水準・外字に大分類される。この分類にしたがってFont SetID ０、Font SetID Ｔ、Font SetID １、Font SetID ２、Font SetID Ｇと識別子がつけられる。その範囲とは、図２に示す「文字コード開始」と「文字コード終了」の範囲である。納めてあるフォントイメージが表す文字コードの範囲を示す。
【００２２】
【表２】
2007245659.tif 000004
【００２３】
表２に示すように、Styleは外字・標準に分類され、この分類にしたがってStyle Ｇ、Style Ｎと識別子がつけられる。Styleは、フォントイメージをメーカが決めたものか（標準；識別子「Ｎ」）、ユーザが決めたものか（外字；識別子「Ｇ」）を意味する。
【００２４】
【表３】
2007245659.tif 000005
【００２５】
表３に示すように、TypeはVecter（Vecter Font；文字輪郭がベクトルデータで納まっている）・Bitmap（Bitmap Font；文字イメージがBitmapで納まっている）に分類される。一般的Font形式の、Bitmap及びVectorの扱いについて以下説明する。標準搭載Font、アウトラインフォント（Outline Font）は、エミュレーションによる解像度指定・アプリからの様々なサイズ指定があっても文字品質を低下させずに文字生成して文書印刷を可能にするという特長がある。Bitmap Fontは、エミュレーションによる解像度単位・アプリからの必要なサイズ単位を用意して搭載するという使い方に留めている。
【００２６】
ここで、本発明の実施形態に係る外字登録について図２を用いて説明する。文字コードは第一水準に含まれているが、字形を変えてみたい場合は、図２に示すＨＤＤ１２上段の形式で登録する。したがって、ＨＤＤ１２上段のFont Fileは、Font SetID １（文字コードは標準フォントと同様）、Style Ｇ（字形を変更）となる。また、文字コードを外字領域に定義した場合（Font SetID Ｇ）、ＨＤＤ１２下段の形式で登録する（Font SetID Ｇ、Style Ｇ）。
【００２７】
人名に外字を用いる場合を例に説明する。ＨＤＤ１２上段のFont SetID １、Style Ｇとは、第一水準(漢字)含まれるが、字形を変え、外字としていることを意味する。例えば、標準Fontでは「吉田」となるが、Font SetID １、Style Ｇでは「土口＋田」となるように人名に使うフォントイメージにて構成されている。「土口＋田」とはParts土とParts口から１つの文字Image（≒吉）として合成し最終的に人名の吉田を意味する。該Font Fileには１つの文字Image（≒吉）、すなわち１文字分のイメージが格納されている。
【００２８】
本発明の実施形態に係る外字ファイルをサーチする際の動作処理について図３を用いて説明する。図３は、本実施形態に係る動作処理の流れを示すフローチャートである。文字コードを指定し（本実施形態では「吉」）（ステップＳ１）、ＨＤＤ１２が先読み媒体として指定された場合は（ステップＳ２／Ｙｅｓ）、ＨＤＤ１２→フォントＲＯＭ１１の順に、Font Headerをサーチし、指定されたコードのFont Fileを探す（ステップＳ３）。このため、文字コードは標準（第一水準）に含まれているが、字形を変えた外字を用いることが出来る。
【００２９】
一方、フォントＲＯＭ１１が先読み媒体として指定されている場合は（ステップＳ２／Ｎｏ）、フォントＲＯＭ１１→ＨＤＤ１２の順に、Font Headerをサーチし、指定されたコードのFont Fileを探す（ステップＳ３）。
【００３０】
上記実施形態により、媒体をサーチする優先順位を変更できるようにするため、ユーザは、Styleを外字（Ｇ）とした外字標準Font File、若しくは元々のStyle（Ｎ）のまま標準Font Fileを使用するか、パフォーマンスを低下させずに切替えることが可能である。ＨＤＤ１２を先にサーチする場合は、標準に含まれる文字コードであっても字形を変えた外字が記憶されていればこれを使用し、フォントＲＯＭ１１を先にサーチする場合は、標準フォントを使用することが出来る。該当する文字コードがない場合は、もう一方の媒体をサーチするため、再度もう一方の媒体をサーチするよう指示する負担がなく、利便性に優れると言える。
【００３１】
本実施形態では、図２に示すように、ＨＤＤ１２上段、文字コードが第一水準に含まれているが（Font SetID １）、字形を変えるため（外字；Style Ｇ）ユーザが登録した「吉」のFont Fileが、あたりとなる。その後、かかるあたりのFont File中の、人名"吉田"の「吉」（＝「土口」）のフォントイメージを読み込み（ステップＳ５）、文字生成部１０で展開する（ステップＳ６）。図２に示すように、外字「吉」のTypeはVectorであるため、VectorからBitmapに展開する。そして、ページバッファ４に書き出す（ステップＳ７）。
【００３２】
また、他の実施形態として、図２に示すＨＤＤ１２の下段の形式（Font SetID Ｇ、Style Ｇ）で登録されているフォントについて説明する。かかるフォントは、ユーザがBitmapでフォントイメージを生成して、文字コードを付与した（外字領域に定義した）外字Font Fileである。本実施形態に係る外字には、Font SetID ０／Ｔ／１／２が使用していない領域の文字コードが使用されている（上記表１参照）。
【００３３】
たとえば、ロゴ「Ｒ」のフォントイメージを、文字コード（０ｘ７５２１）として外字として定義した場合、Font SetID  Ｇに分類され、ＨＤＤ１２に登録される。インターフェース部７（図１参照）経由で文字コード（０ｘ７５２１）が指定されると大分類されてFont SetID  Ｇと識別される。先読み媒体が何れに選択されていても、Font Headerをサーチし、ＨＤＤ１２中のFont SetID  Ｇがあたりとなる。あとはそのファイル中のロゴ「Ｒ」がBitmap形式で読み出される。
【００３４】
上記実施形態により、外字は一般に外字領域（表１；外字文字コードの範囲、７５２１−７５７Ｅ参照）に文字コードを割り振られるので、ドキュメント中に埋め込むときに扱いづらい。しかしながら、人名・教育文字など旁（つくり）が違う文字を標準Font File中の同じコードの字形と入れ替えて埋め込んでおけば（図２；ＨＤＤ１２上段のFont File、Font SetID １  Style  Ｇ）、文字コードを意識せずに外字を埋め込んだ文書作成が可能になる。
【００３５】
本発明の応用としては、例えば基幹系印刷、名刺印刷、戸籍印字が考え得る。
【００３６】
次に、本発明の実施形態に係る外字フォント（ＨＤＤ１２に格納されている）のサイズについて説明する。Sizeとは、Bitmap形式のときは、ドット数で示す。例えば、Size６４は６４×６４ドットである（図４参照）。Outline形式、Vector形式は、元字の座標値のマトリクスで示す。例えば、Size２５６は２５６×２５６座標系である（図４参照）。このままならば、全てのフォントは同じ高さ、幅であるが、９８エミュレーションやLine Printer用等、同じ解像度で印刷しても大きめに印字される文字もあり、この補正を行なうのがScale（図２、Font HeaderのScale）である。
【００３７】
エンジン解像度６００ｄｐｉのときに、６００ｄｐｉ印刷用に設計されたサイズならば、そのままページバッファ４に書き出せば適切な印字が可能である。しかし、エンジン６００ｄｐｉに対して外字６４（４００ｄｐｉ）があててしまったならば（図４参照）、４００ｄｐｉ用の６４×６４ｄｏｔ Bitmapを、６００ｄｐｉ用の外字Imageに拡大する。
【００３８】
外字Fontは元々何らかのエンジン用に製作するので３００ｄｐｉ／４００ｄｐｉ／６００ｄｐｉ用に出来ている。これを６００ｄｐｉ用に変換する(＝拡大)。処理としては下記表４のマトリクスになる。
【００３９】
【表４】
2007245659.tif 000006
【００４０】
全てが整数値での拡大ｏｒ縮小になるアルゴリズムとしては、Bitmap IMAGE ASICを用いても良いし、画素構成によるキャラクタパターンの拡大処理をなす文字変倍方式のような処理を応用して、文字生成部１１にて実施することも可能である。処理した文字イメージはページバッファ４に書き出して処理を完了する。
【００４１】
上記実施形態により、汎用的なBitmap形式で外字imageをサポートするため、ユーザ資産の活用が可能である。また、外字Font FileをFile Headerにて識別することで、Fontサーチする際に、標準Font Fileと同じ扱いにすることができ、Bitmap形式の外字イメージの文字展開が簡単に実現できる。
【００４２】
なお、文字の高さや幅等を揃えるにあたっては、文字高等のデータをテーブルとして持ち、制御する。
【００４３】
以上、本発明を好適な実施の形態に基づき具体的に説明したが、本発明は上記のものに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【図面の簡単な説明】
【００４４】
【図１】本発明の実施形態に係る画像処理装置のブロック構成図である。
【図２】本発明の実施形態に係るフォントＲＯＭ１１とＨＤＤ１２のフォントパーティションの構成を示す図である。
【図３】本発明の実施形態に係るFont Fileサーチの動作処理を示すフローチャートである。
【図４】本発明の実施形態に係るFont Fileの一例を示す図である。
【符号の説明】
【００４５】
１    ホストＰＣ
２    画像処理装置
３    エンジン
４    ページバッファ
５    制御部
６    受信バッファ
７    インターフェース部
８    文字管理部
９    フォントキャッシュメモリ
１０    文字生成部
１１    フォントＲＯＭ
１２    ＨＤＤ
【図１】
2007245659.tif 000007
【図２】
2007245659.tif 000008
【図３】
2007245659.tif 000009
【図４】
2007245659.tif 000010