JP2017102536A - 情報処理システム、情報処理システムの制御方法、情報処理装置およびプログラム - Google Patents

Abstract

【課題】ＯＳが有するフォントのメトリクス情報が変更された場合であっても、帳票のフォーム編集時のレイアウトを維持することが可能となる情報処理システムを提供する。
【解決手段】帳票のフォーム編集時に、当該帳票のフォーム情報に含まれるフォントのメトリクス情報をＯＳから取得する取得手段と、前記フォーム情報とともに前記メトリクス情報を保存する保存手段と、前記帳票のフォーム情報とフィールドデータとをオーバレイ出力することにより帳票ページを生成する生成手段と、を備え、前記生成手段は、帳票ページを生成する際に、前記保存されたメトリクス情報を用いて前記帳票のレイアウト構成を計算する。
【選択図】図１２

Description

本発明は、情報処理システム、情報処理システムの制御方法、情報処理装置およびプログラムに関する。

ペーパーレス化による業務の効率化や省資源化を目的に、紙媒体の情報を文書データに置き換える企業が増加している。例えば、社内で運用されている業務帳票もその対象となることが多く、特に基幹系システムが出力する帳票は大量のページ数を出力するため運用コストが莫大なものになることから、帳票の電子化が積極的に行われている。また、帳票の雛型となるフォーム情報に対して、フィールドデータをオーバレイ処理する（フォームに対してフィールドデータを流し込んで適用する）ことによって、ＰＤＦ形式などの帳票文書データ（帳票イメージ）を作成する方法が提案されている。

帳票文書データは、文字列や表の罫線、ロゴ等の画像で構成されている。帳票文書データに含まれる文字列は、帳票生成プログラム（フォーム）が配置する位置を計算した上で描画することにより出力される。出力する文字列には、フォーム編集用のアプリケーションにおいてフォームを作成・編集する際に各種属性が指定できる。例えば、文字列を描画するためのフォント名やフォントスタイル、文字色や揃え位置等の属性が指定できる。

帳票生成プログラムは、文字位置を計算する際に、指定されたフォントの情報を使用する。使用する情報は、帳票生成プログラムにより様々であるが、例えば、取消線や下線を引く際の位置や、フォントに収録された各文字の最大幅を表す情報などである。例えば、文字の最大幅は、縦書き文字が複数行存在する場合に各行の間隔を計算するために帳票生成プログラムによって利用される。

フォントは、コンピュータ上で文字列を表現するための仕組みである。ＯＳ（オペレーティングシステム）によりフォントの実現方法は様々である。例えば、Ｗｉｎｄｏｗｓ（登録商標）にはＴｒｕｅＴｙｐｅフォントと呼ばれるフォントがある。コンピュータ上で文字を表現するため、ＴｒｙｅＴｙｐｅフォントには、「グリフ」と呼ばれる文字の外形を表現するデータが含まれている。

グリフデータは、各々の文字に必要であり、例えば「あ」という文字のグリフと「い」という文字のグリフは異なるデータとしてそれぞれフォント内部に保持されている。また、フォントは、フォント全体に共通の情報として「メトリクス情報」を有する。前述した取消線や下線を引く際の位置、文字の最大幅等の情報は、メトリクス情報である。メトリクス情報は、フォントとしての属性を表現している。

従来、帳票生成プログラムは、文字位置を計算する際に利用するメトリクス情報を、ＯＳにインストールされたフォントから取得していた。特許文献１は、フォントデータと、フォントデータの利用に関連する処理を内容とする複数のフォント処理関数とを記憶している文字列描画装置を開示している。

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

しかしながら、ＯＳのバージョンアップに伴いフォントがアップデートされた際に、メトリクス情報が変更される場合がある。同じフォントであっても、メトリクス情報が変更された場合には、文字位置計算に影響を及ぼすことになる。すなわち、ＯＳがアップデートされてメトリクス情報が変更されると、従来の文字位置と異なる位置に文字が描画されてしまう。特許文献１では、メトリクス情報が変更された場合については考慮されていない。

本発明は、ＯＳが有するフォントのメトリクス情報が変更された場合であっても、帳票のフォーム編集時のレイアウトを維持することが可能となる情報処理システムを提供することを目的とする。

本発明の一実施形態の情報処理システムは、帳票のフォーム編集時に、当該帳票のフォーム情報に含まれるフォントのメトリクス情報をＯＳから取得する取得手段と、前記フォーム情報とともに前記メトリクス情報を保存する保存手段と、前記帳票のフォーム情報とフィールドデータとをオーバレイ出力することにより帳票ページを生成する生成手段と、を備え、前記生成手段は、帳票ページを生成する際に、前記保存されたメトリクス情報を用いて前記帳票のレイアウト構成を計算する。

本発明の情報処理システムによれば、ＯＳが有するフォントのメトリクス情報が変更された場合であっても、帳票のフォーム編集時のレイアウトを維持することが可能となる。

本発明の一実施形態に係る情報処理システムの構成例を示す図である。 一実施形態に係る情報処理装置のハードウェア構成を示す図である。 帳票生成サーバ上で動作するソフトウェアモジュールの構成例を示す図。 帳票生成サーバによるオーバレイ出力処理を説明する図である。 文字設定ダイアログの一例を示す図である。 クライアント装置のソフトウェアモジュールの構成例を示す図である。 フォーム情報ファイルの内部構成を示す図である。 オーバレイ出力処理を説明するフローチャートである。 埋込済みメトリクス情報リストの一例を示す図である。 埋込済みメトリクス情報リストの一例を示す図である。 フォーム情報ファイルの保存処理の一部を表したフローチャートである。 帳票ページのレイアウト処理を説明するフローチャートである。 文字列の配置位置を計算する処理を示す図である。 異なるメトリクス情報を用いて出力された帳票文書データを示す図である。 欧文帳票の帳票イメージの一部の例を示す図である。 異なるメトリクス情報を用いて出力された帳票文書データを示す図である。

まず、本発明の説明に先立ち、ＯＳから取得されたメトリクス情報の違いが、帳票文書データの出力に及ぼす影響について説明する。図１４は、同じフォントであってもメトリクス情報が異なる場合の帳票文書データの出力例を示す図である。出力イメージ１３０１は、ＯＳがアップデートされる前のメトリクス情報を用いて出力された帳票イメージの一部であり、出力イメージ１３０３は、ＯＳがアップデートされた後のメトリクス情報を用いて出力された帳票イメージの一部である。

アップデート前の出力イメージ１３０１では、罫線の中に縦書き文字列１３０２が収まっている。罫線の大きさは、フォーム編集用のアプリケーションでユーザが指定する。ユーザがフォーム編集用のアプリケーションにおいて縦書き文字列１３０２が収まるように罫線の大きさを操作し、フォームを編集した結果、出力イメージ１３０１が得られる。

しかし、ＯＳのアップデータに伴いフォントがアップデートされ、文字の最大幅を示すメトリクス情報が大きくなった場合に、２行目の縦書き文字列位置が左に移動してしまう。その結果、出力イメージ１３０３のように、縦書き文字列１３０４が罫線の中に収まらなくなってしまう。このように、同じフォーム情報、すなわち同じフォントを利用していても、ＯＳのアップデートにより出力結果が崩れてしまうことがある。

図１６は、同じフォントであってもメトリクス情報が異なる場合の帳票文書データのその他の出力例を示す図である。図１６に示す欧文帳票の場合には、ＯＳがアップデートされる前の出力イメージ１５０１と比べて、ＯＳがアップデートされた後の出力イメージ１５０３の文字列の取消線の位置１５０４が、下方に移動してしまう。本実施形態では、このように、ＯＳのアップデート等に伴いフォントのメトリクス情報が変更された場合であっても、フォーム情報を作成した際のレイアウトを維持した帳票ページを作成することが可能となる。以下、本発明を実施するための形態について図面などを参照して説明する。

（第１実施形態）
図１は、本実施形態に係る情報処理システムの構成例を示す図である。
図１に示す情報処理システムは、帳票生成サーバ１０１とクライアント装置１０２を備える。帳票生成サーバ１０１は、本実施形態の情報処理装置である。帳票生成サーバ１０１は、オーバレイ出力処理を実行する。すなわち、帳票生成サーバ１０１は、テキストデータであるフィールドデータファイルと、所定のフォーム情報を含むフォーム情報ファイルとを重ね合わせて、帳票ページを生成する。そして、帳票生成サーバ１０１は、クライアント装置１０２からのリクエスト（要求）に応じて、仮想プリンタに指示して、帳票ページに対応する印刷データを電子ファイルとして生成する。

クライアント装置１０２は、帳票生成サーバ１０１に対するオーバレイ出力処理のリクエスト、およびプリンタ１０３に対する印刷リクエストを行う。また、ユーザは、クライアント装置１０２において画面操作によりフォーム情報ファイルの作成を行う。プリンタ１０３は、クライアント装置１０２からのリクエストに応じて帳票文書データを紙に印字する処理を行う。

これら帳票生成サーバ１０１、クライアント装置１０２、およびプリンタ１０３の各構成要素は、ネットワーク１００を介して相互に通信可能に接続されている。ネットワークは、例えば、インターネット、ＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等である。なお、ネットワーク１００は、これらに限定されるものではなく、データの送受信が可能であればよく、また、これらの組み合わせにより実現されてもよい。また、各構成要素間のネットワーク１００は、それぞれで異なっていてもよい。

図２は、図１の帳票生成サーバとクライアント装置を実現する情報処理装置のハードウェア構成を示す図である。
図２に示す装置は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１乃至Ｉ／Ｆ２０７を備える。ＣＰＵ２０１は、内部バスで接続される各デバイス（後述のＲＯＭ、ＲＡＭ他）を直接或いは間接的に制御し、本発明を実現するためのプログラムを実行する。

ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）が記憶されている。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３は、ＣＰＵ２０１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりする。

ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）２０４には、基本ソフトウェアであるＯＳ（オペレーティングシステム）やソフトウェアモジュールが記憶されている。ＨＤＤ２０４に代えてＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）を設けるようにしてもよい。入力装置２０５は、ユーザの操作入力に応じた情報を入力する。入力装置２０５は、例えば、不図示のキーボードやポインティングデバイスなどである。出力装置２０６は、情報を出力する。出力装置２０６には、ディスプレイが接続される。Ｉ／Ｆ２０７は、ネットワーク１００に接続するためのインタフェースである。

装置が起動後、ＣＰＵ２０１によりＢＩＯＳが実行され、ＯＳがＨＤＤ２０４からＲＡＭ２０３に実行可能にロードされる。ＣＰＵ２０１は、ＯＳの動作に従って各種ソフトウェアモジュールをＨＤＤ２０４からＲＡＭ２０３に随時、実行可能にロードする。各種ソフトウェアモジュールは、ＣＰＵ２０１によって実行され動作する。また、Ｉ／Ｆ２０７は、ＯＳの動作に従ってＣＰＵ２０１により制御され、外部装置との通信を実現している。

図３は、帳票生成サーバ上で動作するソフトウェアモジュールの構成例を示す図である。
各ソフトウェアモジュールは、図２に示したＨＤＤ２０４に記憶されており、ＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。帳票生成サーバ１０１は、アクセス制御部３０１乃至帳票印刷部３０９を備える。アクセス制御部３０１は、クライアント装置１０２からのリクエストに応じてユーザ認証を行う。

ページ生成部３０２は、クライアント装置１０２にレスポンスを返すためのＷｅｂページを生成する。データアクセス部３０３は、各データベース（ＤＢ、記憶手段）３０５乃至３０８へのアクセス処理を行う。帳票生成部３０４は、データアクセス部３０３を介して、フォーム情報ＤＢ３０６からフォーム情報ファイルを読み出す。また、帳票生成部３０４は、データアクセス部３０３を介して、フィールドデータＤＢ３０７からフィールドデータファイルを読み出す。

そして、帳票生成部３０４は、読み出したフォーム情報ファイルが示すフォーム情報４０１と、フィールドデータファイルが示すフィールドデータとを重ね合わせて、帳票ページを生成する。また、帳票生成部３０４は、仮想プリンタなどのソフトウェアを利用して、帳票ページの電子ファイルを生成する。帳票データＤＢ３０５には、帳票データが格納される。

帳票データは、帳票名、所有者などの情報を示し、当該帳票がどのフォーム情報ファイルとフィールドデータファイルとから生成されたかを表す情報を有する。また、帳票データは、当該帳票のオーバレイ結果である帳票ページを示す情報を有する。フォーム情報ＤＢ３０６には、フォーム情報ファイルが格納される。フィールドデータＤＢ３０７には、フィールドデータファイルが格納される。帳票ページＤＢ３０８には、帳票生成部３０４によって生成された帳票ページファイルが格納される。帳票印刷部３０９は、クライアント装置１０２からのリクエストに応じて帳票ページを印刷可能なフォーマットに変換する。

図６は、クライアント装置上で動作するソフトウェアモジュールの構成例を示す図である。
各ソフトウェアモジュールは、図２に示したＨＤＤ２０４に記憶されており、ＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。フォーム情報設計システム６０１は、フォーム情報ファイルを作成する。

ユーザは、フォーム情報設計システム６０１を用いてフォーム情報ファイルに罫線やテキスト、ロゴ、画像といったオブジェクトの配置を画面操作により行い、それらオブジェクトの属性を設定することによりフォーム情報ファイルを作成する。フォーム情報設計システム６０１は、ＵＩ表示部６０２乃至フォーム情報保存部６０４を備える。ＵＩ表示部６０２は、ユーザがフォーム情報ファイルを作成するためのユーザインタフェースを表示する。具体的なインタフェースの例については、図４を参照して後述する。

フォーム情報保持部６０３は、ユーザが配置した図形およびその属性等のフォーム情報をＲＡＭ２０３に保持する。また、フォーム情報保持部６０３は、ユーザインタフェースの操作によるフォーム情報の変更を検知し、保持しているフォーム情報へ反映する。フォーム情報保存部６０４は、フォーム情報保持部６０３がＲＡＭ２０３に保持しているフォーム情報を、フォーム情報ファイルとしてＨＤＤ２０４に保存する。

図４は、帳票生成サーバ１０１によるオーバレイ出力処理を説明する図である。
オーバレイ出力とは、原稿用紙形式の枠線などの情報を記録するフォーム情報とテキスト形式のデータ（フィールドデータ）を重ねあわせて印刷することである。オーバレイ出力の結果を紙ではなく、電子ファイルとして出力することも可能である。

フォーム情報は、クライアント装置１０２にインストールされたフォーム情報設計システム６０１を利用して作成される。フォーム情報は、フィールドデータに依存しない固定的な図形（フォーム図形４０８）と、受け取ったフィールドデータを指定した出力書式に従って表示する図形（フィールド図形４０９）から構成されている。フィールド図形を作成するには、予めフィールドデータを受け取るための項目（フィールド）を作成する必要がある。フィールドは、フォーム情報設計システム６０１にて表示された専用の画面から作成する。

フィールド図形が作成されると、作成元であるフィールドとの関連付けが内部的に行われる。表形式のフィールド図形（表図形）４０２の場合、フィールドデータをレコード単位に受け取る必要があるため、レコードフィールド４０３が作成される。他のフィールド図形のデータの演算結果からフィールドデータを生成する形式のフィールドは、計算列フィールドと定義する。

また、指定した集計方法で集計し、フィールドデータを生成する形式のフィールドは、集計フィールドと定義する。例えば、フィールド図形４０４の場合、どのフィールドとどのような集計方法が指定されているかを表す集計フィールド４０５が作成されている。帳票生成サーバ１０１は、フィールド図形が定義されたフォーム情報ファイルと、対応するフィールドデータファイルとを読み込む。そして、帳票生成サーバ１０１は、読み込んだフォーム情報ファイルとフィールドデータファイルとを重ね合わせることでオーバレイ出力処理を実行する。図４の４０７は、オーバレイ出力処理結果の例を示す。

図５は、フォーム図形およびフィールド図形の表示文字列に関する設定を行うユーザインタフェースの一例を示す図である。
図５では、ユーザインタフェースの一例として文字設定ダイアログ５０１を示す。文字設定ダイアログ５０１は、フォーム情報設計システム６０１のＵＩ表示部６０２により表示される。フォント名指定５０２にて、各図形で表示する文字列のフォント名が選択される。帳票ページを作成する際には、フォント名指定５０２で指定したフォント名に合致するフォントがＯＳにより選択され、文字列が描画される。

フォントスタイル指定５０３にて、使用するフォントスタイルが選択される。フォントサイズ指定５０４にて、使用するフォントのサイズが選択される。文字色指定５０５にて、各図形で表示する文字列の色が選択される。下線指定５０６にて、文字列に下線を引くか否か、および下線の種類が選択される。例えば、下線の種類として「実線」「点線」「一点鎖線」「二点鎖線」等の種類が選択できる。取り消し線指定５０７にて、文字列に取り消し線を引くか否か、および取り消し線の種類が選択される。例えば、取り消し線の種類として「実線」「点線」「一点鎖線」「二点鎖線」等の種類が選択できる。

図７は、フォーム情報設計システム６０１が備えるフォーム情報保存部６０４が保存するフォーム情報ファイルの内部構成を示す図である。
フォーム情報ファイル７０１は、フォーム図形リスト７０２、フィールド図形リスト７０９、および埋込済みメトリクス情報リスト７１３から構成される。フォーム図形リスト７０２は、フォーム情報ファイルに定義された全てのフォーム図形のリストである。

図７に示す例では、フォーム図形Ａ７０３とフォーム図形Ｂ７０６が定義されている。フォーム図形Ａ７０３およびフォーム図形Ｂ７０６は、それぞれのフォーム図形の属性を保持する。使用フォント情報７０４および７０７は、それぞれのフォーム図形の文字列を描画する際に使用するフォントに関する情報を保持する。例えば、フォーム図形Ａ７０３
の使用フォントは、「フォントＡ」であり、フォントスタイルは、「標準」である。文字色情報７０５および７０８は、それぞれのフォーム図形の文字列の描画色を保持する。例えば、フォーム図形Ｂ７０６の文字色は、「赤」である。

フィールド図形リスト７０９は、フォーム情報ファイルに定義された全てのフィールド図形のリストである。図７に示す例では、フィールド図形Ａ７１０が定義されている。フィールド図形Ａ７１０は、フィールド図形の属性を保持する。フォーム図形の場合と同様に、使用フォント情報７１１や文字色情報７１２等の構成要素を有する。埋込済みメトリクス情報リスト７１３は、フォーム情報ファイルに定義されたフォーム図形およびフィールド図形で指定されているフォントのメトリクス情報のリストである。

図９および図１０は、埋込済みメトリクス情報リストの一例を示す図である。
埋込済みメトリクス情報リスト７１３は、後述する図１１のフローチャートの処理によりフォーム情報ファイルに保存される。埋込済みメトリクス情報リスト７１３には、フォーム情報ファイルで定義されたフォーム図形およびフィールド図形で指定されている各フォントのメトリクス情報が、フォント名およびフォントスタイルごとに分類されて保存されている。

図９および図１０に示す例では、フォント名が「フォントＡ」９０１および「フォントＢ」９０９であるフォントのメトリクス情報が定義されている。また、図に示すように「フォントＡ」９０１は、各フォントスタイル（９０２、９０６、９０７、９０８）ごとにメトリクス情報を保存している。それぞれのメトリクス情報は、例えば９０３のように、属性と属性値とが区別できるように構成されている。

図９に示す例では、埋込済みメトリクス情報リスト７１３は、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で表現されている。９０３のように、ＸＭＬのタグ名が属性名を、タグ内の要素の値が属性値を表している。なお、本実施形態では、ＸＭＬ形式で表現しているが、属性と属性値とが区別できればよく、例えば、フォーム情報設計システム６０１固有のバイナリ形式であってもよい。

また、メトリクス情報の種類としては、フォーム情報ファイルに定義されたフォーム図形およびフィールド図形の文字列を描画する際に行うレイアウト構成の計算処理で使用するものが全て保存される。例えば、フォントに定義された全グリフの最大文字幅を示す属性「ｔｍＭａｘＣｈａｒＷｉｄｔｈ」（最大文字幅属性９０４）や、取り消し線の位置を示す属性「ｏｔｍｓＳｔｒｉｋｅｏｕｔＰｏｓｉｔｉｏｎ」（取り消し線位置属性９０５）などがある。

図１１は、フォーム情報設計システムが備えるフォーム情報保存部６０４が実行するフォーム情報ファイルの保存処理の一部を表したフローチャートである。
この処理は、フォーム情報設計システム６０１が備えるＵＩ表示部６０２が表示したユーザインタフェースを用いて、ユーザがフォーム情報ファイルの保存を指示した際に実行される。ここでは、既にユーザが画面操作により各フォーム図形やフィールド図形の配置および属性設定を実施し、それらのフォーム情報が、フォーム情報保持部６０３によりＲＡＭ２０３に保持されている状態を前提とする。

ステップＳ１００１において、フォーム情報保存部６０４は、ＲＡＭ２０３に保持されたフォーム情報から、埋込済みメトリクス情報リストを取得する。フォーム情報ファイルが新規に作成された際は、フォーム情報に埋込済みメトリクス情報リストは含まれていないため、その場合の取得結果は空となる。ステップＳ１００２において、フォーム情報保存部６０４は、取得したフォーム情報から、フォーム図形およびフィールド図形で使用されているフォントのリスト（使用フォントリスト）を取得する。

ここで、ＲＡＭ２０３に保持されているフォーム情報は、図７で示したフォーム情報ファイル７０１と同等の構成で保持されている。フォーム情報保存部６０４は、フォーム図形リスト７０２およびフィールド図形リスト７０９に含まれている全てのフォーム図形およびフィールド図形の構成要素を確認し、そこで指定されているフォントをリストに列挙する。その際、フォント名とフォントスタイルとが同一である場合は、同じフォントを指定したとみなし、フォント名とフォントスタイルとを重複して保持しないようにする。

フォント名が同じであってもフォントスタイルが異なる場合には、別のフォントとしてリストに列挙する。また、フォントサイズは、ステップＳ１００２の処理では意識されない。フォーム情報保存部６０４は、ステップＳ１００２で取得した使用フォントリストをＲＡＭ２０３に保持する。ステップＳ１００３において、フォーム情報保存部６０４は、ステップＳ１００２にて取得した使用フォントリストから１つずつフォントを取り出し、取り出したフォント毎に後続のステップＳ１００４〜Ｓ１００６の処理を行う。

ステップＳ１００４において、フォーム情報保存部６０４は、ステップＳ１００３で取り出した使用フォントのフォント名およびフォントスタイルに合致するフォントが、埋込済みメトリクス情報リスト７１３に存在するか否かを判断する。埋込済みメトリクス情報リスト７１３には、メトリクス情報が、フォント名およびフォントスタイルごとに保持されている。フォーム情報保存部６０４は、フォント名およびフォントスタイルを表現するタグを検索することで、合致するフォントが存在するか否かを判定する。

ステップＳ１００４において、埋込済みメトリクス情報リスト７１３に合致するフォントが存在すると判断された場合には、ステップＳ１００７の処理に進む。一方、ステップＳ１００４において、埋込済みメトリクス情報リスト７１３に合致するフォントが存在しないと判断された場合には、ステップＳ１００５の処理に進む。ステップＳ１００５において、フォーム情報保存部６０４は、クライアント装置１０２上のＯＳからステップＳ１００３で取り出した使用フォントのメトリクス情報を取得する。

Ｗｉｎｄｏｗｓ（登録商標）にインストールされているＴｒｕＴｙｐｅフォントからフォントのメトリクス情報を取得するためには、Ｗｉｎｄｏｗｓ（登録商標）が提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を使用する。ＡＰＩにフォント名を指定することで各フォントの最大文字幅属性９０４や取り消し線位置属性９０５などの値を取得する事ができる。

ステップＳ１００６において、フォーム情報保存部６０４は、ステップＳ１００３で取り出した使用フォントのフォント名およびフォントスタイルと、ステップＳ１００５で取得したメトリクス情報とを、埋込済みメトリクス情報リスト７１３の形式に整形する。そして、整形したそれらの情報を、ＲＡＭ２０３に保持されている埋込済みメトリクス情報リスト７１３へ追加する。ステップＳ１００７において、フォーム情報保存部６０４は、埋込済みメトリクス情報リスト７１３に含まれるフォント毎に後続のステップＳ１００８およびステップＳ１００９の処理を行う。

ステップＳ１００８において、フォーム情報保存部６０４は、埋込済みメトリクス情報リスト７１３に含まれるフォントが、ステップＳ１００２でＲＡＭ２０３に保持されたフォーム情報から取得した使用フォントリストに含まれているか否かを判断する。ステップＳ１００２で保持した使用フォントリストは、フォント名およびフォントスタイルを区別して保持している。埋込済みメトリクス情報リスト７１３に存在するフォントのフォント名およびフォントスタイルを、使用フォントリストに存在するフォント名およびフォントスタイルと比較し、合致するものがあれば使用フォントリストに含まれていると判断する。

ステップＳ１００８において、埋込済みメトリクス情報リスト７１３に含まれるフォントが使用フォントリストに存在すると判断された場合には、ステップＳ１０１０の処理に進む。一方、ステップＳ１００８において、埋込済みメトリクス情報リスト７１３に含まれるフォントが使用フォントリストに存在しないと判断された場合には、ステップＳ１００９の処理に進む。ステップＳ１００９において、フォーム情報保存部６０４は、ステップＳ１００８で判断したフォントについての情報を、埋込済みメトリクス情報リスト７１３から削除する。

これにより、フォーム情報で使用されていないフォントのメトリクス情報が削除される。フォーム情報（フォーム情報ファイル）は、繰り返し編集されることが想定される。再編集によりフォーム図形およびフィールド図形の増減が発生した場合に、使用されているフォントの増減が発生しうるが、ステップＳ１００９の処理を行うことにより不要なメトリクス情報をフォーム情報ファイルから削除できる。

ステップＳ１０１０において、フォーム情報保存部６０４は、ＲＡＭ２０３に保持され、ステップＳ１００６およびステップＳ１００９で変更された埋込済みメトリクス情報リスト７１３をフォーム情報ファイルに追加し、フォーム情報ＤＢ３０６に保存する。以上の処理により、フォーム情報ファイルに定義されたフォーム図形およびフィールド図形で使用されている全てのフォントのメトリクス情報が、埋込済みメトリクス情報リスト７１３としてフォーム情報ファイルに保存される。

図８は、帳票生成サーバが実行するオーバレイ出力処理を説明するフローチャートである。
ステップＳ８０１において、帳票生成部３０４は、ＨＤＤ２０４に保存されたフォーム情報ファイルから、描画対象の図形（フィールドデータと関連付いていないフォーム図形およびフィールドデータと関連付いているフィールド図形）の情報を取得する。

取得する情報は、ユーザが文字設定ダイアログ５０１で指定した各図形のフォント名、フォントスタイル、フォントサイズ等である。レイアウト構成の計算および描画に必要な情報は、全てフォーム情報ファイルに格納されており、ステップＳ８０１の処理により必要な情報は全て取得される。ステップＳ８０２において、帳票生成部３０４は、フォーム情報ファイルおよびフィールドデータファイルを使用して出力する帳票ページのレイアウト構成を計算する。レイアウト構成を計算する処理の詳細については、図１１を参照して説明する。

ステップＳ８０３において、帳票生成部３０４は、ステップＳ８０２で得られたレイアウト構成に従い、各図形の描画処理を行う。ステップＳ８０４において、帳票生成部３０４は、全ての図形の描画命令が完了したか否かを判断する。ステップＳ８０４において、全ての描画命令が完了していないと判断された場合は、処理はステップＳ８０１に戻り、帳票生成部３０４は、次の描画命令を行う。

一方、ステップＳ８０４において、全ての図形の描画命令が完了したと判断された場合には、帳票生成部３０４は、ステップＳ８０５の処理を行う。ステップＳ８０５において、帳票生成部３０４は、描画処理の結果であるＰＤＬ情報（プリンタに対して描画を指示するためのページ記述言語）を利用して、仮想プリンタを介してＰＤＦ形式の帳票ページを生成する。

図１２は、帳票生成サーバが備える帳票生成部が実行する、帳票ページのレイアウト処理を説明するフローチャートである。
ステップＳ１１０１において、帳票生成部３０４は、フォーム情報ファイル７０１から埋込済みメトリクス情報リスト７１３を取得する。取得した埋込済みメトリクス情報リスト７１３は、ＲＡＭ２０３に保持する。

次に、帳票生成部３０４は、ステップＳ１１０２からステップＳ１１１２の処理により、フォーム情報ファイルに定義されたフォーム図形およびフィールド図形ごとのレイアウト処理を行う。ステップＳ１１０３において、帳票生成部３０４は、処理対象の図形のフォント情報を取得する。具体的には、処理対象の図形がフォーム図形であれば、フォーム情報ファイル７０１のフォーム図形リスト７０２から処理対象の図形を検索し、ヒットした図形の使用フォント情報（７０４または７０７）からフォント名およびフォントスタイルを取得する。

また、処理対象の図形がフィールド図形であれば、フォーム情報ファイル７０１のフィールド図形リスト７０９から処理対象の図形を検索し、ヒットした図形の使用フォント情報７１１からフォント名およびフォントスタイルを取得する。ステップＳ１１０４において、帳票生成部３０４は、ステップＳ１１０３で取得したフォント名およびフォントスタイルに合致するフォントのフォントキャッシュオブジェクトがＲＡＭ２０３に存在するか否かを判断する。

フォントキャッシュオブジェクトは、以下の理由により処理の効率化のために用いられる。すなわち、フォーム情報ファイルは、図７に示したように、図形ごとにフォント名およびフォントスタイルを保存しており、１つのフォーム情報ファイルにおいて、同一のフォント名およびフォントスタイルが指定されうる。このため、複数の図形で同じフォント名およびフォントスタイルの場合がありうる。

同じフォント名およびフォントスタイルの場合には、フォントのメトリクス情報は同じため、後述するＯＳからのメトリクス情報（システム・メトリクス情報）の取得処理を同じフォントおよびフォントスタイルに対して繰り返し行うのは無駄である。これを回避するためにフォントキャッシュオブジェクトを用いて、後述するステップＳ１１０９でＲＡＭ２０３に保持されたフォントのメトリクス情報を保持する。なお、処理の効率化のためにフォントキャッシュオブジェクトを用いているため、本実施形態でフォントキャッシュオブジェクトは必須ではない。

ステップＳ１１０４において、合致するフォントのフォントキャッシュオブジェクトが存在すると判断された場合には、処理はＳ１１１０に進む。一方、ステップＳ１１０４において、合致するフォントのフォントキャッシュオブジェクトが存在しないと判断された場合には、処理はステップＳ１１０５に進む。ステップＳ１１０５において、帳票生成部３０４は、帳票生成サーバ１０１上のＯＳからステップＳ１１０３で取得した使用フォントのメトリクス情報（システム・メトリクス情報）を取得する。具体的な取得方法は、ステップＳ１００５の処理と同様である。

ステップＳ１１０６において、帳票生成部３０４は、ステップＳ１１０３で取得したフォント名およびフォントスタイルに合致するフォントが、ステップＳ１１０１で取得した埋込済みメトリクス情報リスト７１３に存在するか否かを判断する。フォント名およびフォントスタイルが合致するフォントが存在すると判断する。具体的な判定方法についてはステップＳ１００４の処理と同様である。

ステップＳ１１０６において、埋込済みメトリクス情報リスト７１３に合致するフォントが存在すると判断された場合には、ステップＳ１１０７の処理に進む。ステップＳ１１０６において、埋込済みメトリクス情報リスト７１３に合致するフォントが存在しないと判断された場合には、ステップＳ１１０９の処理に進む。ステップＳ１１０７において、帳票生成部３０４は、埋込済みメトリクス情報リスト７１３から、合致したフォントのメトリクス情報を取得する。

例えば、フォント名が「フォントＡ」およびフォントスタイルが「標準」のフォントが、処理対象の図形の使用フォントであった場合に取得されるメトリクス情報は以下である。すなわち、「ｔｍＨｅｉｇｈｔ」（ベースラインからの高さ情報９０３）、最大文字幅属性９０４、および取り消し線位置属性９０５など、全てのメトリクス情報の値が取得される。ステップＳ１１０８において、帳票生成部３０４は、ステップＳ１１０５で取得したシステム・メトリクス情報に、ステップＳ１１０７で埋込済みメトリクス情報リスト７１３から取得したメトリクス情報を上書きする。

埋込済みメトリクス情報リスト７１３のメトリクス情報には、システム・メトリクス情報が有する属性のうち、一部の属性が定義されている。従って、ステップＳ１１０８の処理により、システム・メトリクス情報の一部の属性値が、埋込済みメトリクス情報リスト７１３の属性値により上書きされる。ステップＳ１１０９において、帳票生成部３０４は、フォントキャッシュオブジェクトを作成し、当該オブジェクトにシステム・メトリクス情報の全ての属性を設定する。フォントキャッシュオブジェクトに設定されたメトリクス情報は、後述する文字列の配置位置計算処理に使用される。

ステップＳ１１１０において、帳票生成部３０４は、フォントキャッシュオブジェクトから全てのメトリクス情報を取得する。ステップＳ１１１１において、帳票生成部３０４は、ユーザが文字設定ダイアログ５０１で属性として指定したフォーム図形またはフィールド図形のフォントサイズに合致するようにステップＳ１１１０で取得した各メトリクス情報の値を補正する。

具体的には、フォントサイズは、フォーム図形（７０３または７０６）またはフィールド図形Ａ７１０の不図示の設定情報として、フォーム情報ファイル７０１に保存されている。補正処理は、フォントサイズ（フォントの高さ指定）と、メトリクス情報の「ｔｍＨｅｉｇｈｔ」（ベースラインからの高さ情報９０３）とで比率計算を行う。

例えば、フォント名が「フォントＡ」およびフォントスタイルが「標準」のフォントのフォントサイズ（フォントの高さ指定）が「１０ｐｔ」だった場合には、最大文字幅属性９０４の値は、次のように算出される（１ｐｔは０．３５ｍｍとする）。
３．５ × ４５２５ ÷ ３０７２

さらに、算出された値はｍｍ単位のため、帳票生成部３０４は、ＯＳが提供するテキスト描画のためのＡＰＩで指定可能な単位に変換する。ステップＳ１１１２において、帳票生成部３０４は、ステップＳ１１１１で補正済みのメトリクス情報を用いて処理対象の図形において描画する文字列の各文字の配置位置を計算する。

図１３は、文字列の配置位置を計算する処理を示す図である。
図１３では、文字１２０５から、縦書きで２行の文字列が配置されている（この２行が１つのフィールド図形に描画されている）。１行目の最初の文字１２０５は、フォーム情報ファイルに含まれるフィールド図形の配置位置の情報から、余白や揃え設定に応じて相対的に決定される。文字１２０５から始まる各文字のグリフは、各行の中心線１２０２および中心線１２０３に揃えられる。

帳票生成部３０４は、ステップＳ１１１１で補正済みのメトリクス情報を使用して、２行目の中心線１２０３の配置位置を決定する。この場合、メトリクス情報のうち、最大文字幅属性９０４が使用される。例えば、１行目の中心線１２０２のＸ座標が１００の場合、当該Ｘ座標に最大文字幅属性９０４の属性値を加えたものが、２行目の中心線１２０３のＸ座標となる。

以上のように、フォーム情報ファイルに保存されたメトリクス情報（本実施形態では最大文字幅属性９０４の値）を使用して文字位置を計算することにより、ＯＳに搭載されたフォントのバージョンに依存せず、同等に文字位置を求めることができる。すなわち、ＯＳが有するフォントのメトリクス情報が変更された場合であっても、帳票のフォーム編集時のレイアウトを維持することが可能となる。

（第２実施形態）
本実施形態では、欧文帳票において本発明を適用する例を示す。
図１５は、欧文帳票の帳票イメージの一部の例を示す図である。帳票イメージ１４０１には、欧文で数行の文字列が描画されている。そのうち、２行目および３行目には取消線が引かれている。取消線の位置は、フォントのメトリクス情報に含まれている。グリフ１４０２に対して、どの位置に取消線を引けばよいかがメトリクス情報の「フォント位置」により示される。帳票生成部３０４は、フォーム情報ファイルに保存されたメトリクス情報のうち、取消線の位置情報を利用して取消線を引く（描画する）。これにより、ＯＳがアップデートされた場合であっても同じ位置に取消線を引くことができる。

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

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

１０１ 帳票生成サーバ
３０４ 帳票生成部
３０６ フォーム情報ファイル
１０２ クライアント装置
６０１ フォーム情報設計システム

Claims (8)

1. 帳票のフォーム編集時に、当該帳票のフォーム情報に含まれるフォントのメトリクス情報をＯＳから取得する取得手段と、
   前記フォーム情報とともに前記メトリクス情報を保存する保存手段と、
   前記帳票のフォーム情報とフィールドデータとをオーバレイ出力することにより帳票ページを生成する生成手段と、を備え、
   前記生成手段は、帳票ページを生成する際に、前記保存されたメトリクス情報を用いて前記帳票のレイアウト構成を計算する、ことを特徴とする情報処理システム。
2. 前記保存手段は、既に保存されているメトリクス情報のうち使用されていないフォントに関するメトリクス情報を削除する、ことを特徴とする請求項１に記載の情報処理システム。
3. 前記取得手段は、前記帳票のフォーム情報に含まれるフォントのフォント名及びフォントスタイルごとにメトリクス情報を取得し、
   前記保存手段は、前記フォント名及びフォントスタイルごとのメトリクス情報を保存する、ことを特徴とする請求項１または２に記載の情報処理システム。
4. 前記レイアウト構成は、少なくとも帳票ページに含まれる文字の配置、当該文字の取り消し線の配置、当該文字の下線の配置、および文字列の各行の間隔を含む、ことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記生成手段は、
   前記帳票ページを生成する際に、前記帳票のフォーム情報に含まれるフォントのメトリクス情報をＯＳから取得し、当該ＯＳから取得したメトリクス情報を前記保存手段が保存したメトリクス情報で上書きしたものをキャッシュしておき、
   同じフォント名およびフォントスタイルのメトリクス情報が既にキャッシュされていた場合には、前記ＯＳからメトリクス情報を取得しない、ことを特徴とする請求項１ないし４のいずれか１項に記載の情報処理システム。
6. 帳票のフォーム編集時に、当該帳票のフォーム情報に含まれるフォントのメトリクス情報をＯＳから取得する取得工程と、
   前記フォーム情報とともに前記メトリクス情報を保存する保存工程と、
   前記帳票のフォーム情報とフィールドデータとをオーバレイ出力することにより帳票ページを生成する生成工程と、を有し、
   前記生成工程において帳票ページを生成する際に、前記保存されたメトリクス情報を用いて前記帳票のレイアウト構成を計算する、ことを特徴とする情報処理システムの制御方法。
7. 帳票のフォーム編集時に、当該帳票のフォーム情報に含まれるフォントのメトリクス情報をＯＳから取得する取得手段と、
   前記フォーム情報とともに前記メトリクス情報を記憶手段に保存する保存手段と、を備え、
   サーバ装置は、前記帳票のフォーム情報とフィールドデータとをオーバレイ出力することにより帳票ページを生成する際に、前記記憶手段に保存されたメトリクス情報を用いて前記帳票のレイアウト構成を計算する、ことを特徴とする情報処理装置。
8. 請求項７に記載の情報処理装置の各手段としてコンピュータを機能させるためのプログラム。

Images