フォームと後づけデータをオーバレイ印刷して表形式の帳票を生成するオーバレイ印刷システムにおいて、ページ内の表の領域一杯まで行を詰めるために、行内の各文字列単位で行を分断し、分断後の行だけを次ページに送る場合に、表を1行ずつ描画していき、行が表の領域を超えるかどうか判断するステップと行が表の領域を超える場合に、各セルの文字列について、何行まで表の領域内に収まるかを判定するステップと前記文字列の最後が改行コード、特定の文字であるかどうかを判定するステップと前記で特定の文字で合った場合に、1つ前の行の文字列について、前期判定を行うステップと前記判定で特定の文字でないと判定された場合に、その文字列までを分断すると確定するステップとを備えることを特徴とするオーバレイ印刷システム。本発明で解決しようとする課題は、上記で述べたデータを次ページに送るときのもので、特に行の分断が発生したときに発生するものである。以下に図8を用いて詳細な課題を説明する。図8の後付けデータ801は、表の4行分のデータが記載されている。801内のnという文字列808は、改行を意味している。後付けデータとフォーム802でオーバレイ印刷した結果が804、805であり、804が1ページ目で805が2ページ目である。1ページ目内の表の3行目806の途中で表がページ内で収まらなくなったため、3行目で行の分断が発生し、分断後のデータ807が2ページ目に送られている。元の3行目のデータはGG県H市nI県JJ市nKKK県LLL市であり、改行nで区切ると、このデータはGG県H市、I県JJ市、KKK県LLL市の3つに分けることができる。そのためオーバレイした結果を見るユーザも、この3つに分けた個々のデータは、複数のページでまたがらずに、1つのページ内でみれたほうが見やすくなる。しかし図8のオーバレイ結果804、805をみると、2ページ目で送られたデータ807はLL市であり、KKK県LLL市の途中で行の分断が発生してしまっている。そのため結果として、非常に見栄えの悪い表になってしまっている。つまり、後付けデータの内容を考慮せず、単純にページ内に表が収まるところで行の分断を行うと、非常に見栄えの悪い表ができてしまう場合がある。これが本発明で解決しようとしている課題である。フォームと後づけデータをオーバレイ印刷して表形式の帳票を生成するオーバレイ印刷システムにおいて、ページ内の表の領域一杯まで行を詰めるために、行内の各文字列単位で行を分断し、分断後の行だけを次ページに送る場合に、表を1行ずつ描画していき、行が表の領域を超えるかどうか判断するステップと行が表の領域を超える場合に、各セルの文字列について、何行まで表の領域内に収まるかを判定するステップと前記文字列の最後が改行コード等、特定の文字であるかどうかを判定するステップと前記で特定の文字で合った場合に、1つ前の行の文字列について、前期判定を行うステップとを備えることを特徴とするオーバレイ印刷システム。行の分断機能を使用することで印刷用紙の節約を行いつつも、表の見栄えを損なわないようになる。図8の例に対して本発明を適用すると、図9のようなオーバレイ結果になる。<システム構成図>図1Aは帳票等のデータを印刷するシステム100を図示している。この中で示された方法は図1Bで詳しく説明される汎用コンピュータモジュール101で実践される。図1Bで記述されるプロセスは、コンピュータモジュール101内で実行され、システム100上で実施可能となるフォーム作成アプリケーションプログラム121のようにソフトウェアの全体、あるいは一部分で実行される。特にレイアウト編集、設定ファイル編集や必然的に起こる印刷のステップはコンピュータ101によって実行されるソフトウェアの指示によって実施される。ソフトウェアは例えば以下に記述されるような記憶装置を含むコンピュータの可読媒体に格納される。ソフトウェアはコンピュータの可読媒体からコンピュータにロードされ、コンピュータ101によって実行される。そのようなソフトウェアや媒体に記録されたコンピュータプログラムを持つコンピュータの可読媒体はコンピュータプログラム製品である。そのコンピュータでのコンピュータプログラム製品の使用は望ましくもドキュメントのレイアウト編集やデータ印刷に有利な装置をもたらす。コンピュータモジュール101はキーボード132やマウス133のようなポインティングデバイスなどの入力装置をつなぎ、ディスプレイ装置144や状況に応じてはローカルプリンタ145を含む出力装置を連結する。入力/出力インターフェース138はコンピュータモジュール101をネットワーク接続107から接続してシステム100の他のコンピュータ装置につなげることができる。そのネットワーク接続107の典型はローカルエリアネットワークLAN、あるいはワイドエリアネットワークWANである。コンピュータモジュール101は典型的に少なくとも1つのプロセッサーユニット135を含む。同様に、例えば半導体のランダムアクセスメモリRAMやリードオンリーメモリROMから構成されるメモリユニット136を含む。同様にビデオインタフェース137を含むINPUT/OUTPUTI/Oインターフェースを含む。さらにキーボード132やマウス133のためのI/Oインターフェース143を含んでいる。記憶装置139は典型的にハードディスクドライブ140やフロッピー登録商標ディスクドライブ141を含んでいる。図には示されていないが磁気テープドライブもまた使用される可能性がある。CD-ROMドライブ142は不揮発性のデータソースとして提供される。コンピュータモジュール101は相互接続バス134を介して通信を行うコンピュータモジュール101のコンポーネント135から143を利用する。図に記述した配置コンピュータの例ではIBM互換PCやSUN社のSparcStation、あるいはそれらを含んだコンピュータシステムが考えられる。フォーム作成アプリケーションプログラム121は典型的にハードディスクドライブ140に常駐し、プロセッサ135により実行、読み込み、コントロールされる。プログラム121の媒介記憶装置とネットワーク1020からフェッチされるデータはハードディスクドライブ140に呼応して半導体メモリ136を使用する。いくつかのインスタンスではアプリケーションプログラム121がCD-ROMやフロッピーディスク上でエンコードされ、対応するドライブ142や141を通じて読み込まれユーザに提供される。あるいはもう一つの方法としてアプリケーションプログラム121はネットワーク接続107からユーザによって読み込まれるかもしれない。さらにソフトウェアは磁気テープまたはROMなど、他の適当な大きさのコンピュータ可読媒体からコンピュータモジュール101内にロードされる可能性もある。前述は単に関連するコンピュータ可読メディアの模範である。他のコンピュータ可読媒体も使用される可能性はある。またフォーム作成と名づけられたアプリケーション121はフォーム作成や印刷を行うよう指示し、2つのソフトウェアコンポーネントを含んでいる。これらのうち1つめのコンポーネントはライブラリ105であり、これはオーバレイ印刷処理等の処理を行うソフトウェアコンポーネントである。2つめのコンポーネントであるユーザインターフェース103はユーザにフォームや設定ファイルを作成させるメカニズムを提供する。ユーザインターフェース103とライブラリ105はコミュニケーションチャネル123を介して通信する。ドキュメント生成のためのデータソースは一般的にデータベースアプリケーションを動かしている他のコンピュータによって構成されたデータベースサーバー117上にある典型的なデータベース119である。ホストコンピュータ101はネットワーク接続107の手段によってデータベースサーバー117と通信する。フォーム作成アプリケーション121はホストコンピュータ101か一般的に他のコンピュータで構成されるファイルサーバー115に保存されるフォームまたは設定ファイルを生成する。これらのドキュメントはホストコンピュータ101のローカルファイルシステムに保存されるか、ファイルサーバー115に保存されるか、あるいはプリンタ113に直接印刷される。プリントサーバー109は直接ネットワークにつながっていないプリンタにネットワーク機能を提供するコンピュータである。プリントサーバー109とプリンタ113は典型的な通信チャネル111を介して接続される。図2は中間ファイルを使用した場合の、帳票等のデータを印刷するシステム200の一例を図示している。エンジンサーバー201は典型的なコンピューターである。ファイルサーバー115に保存されたフォームは印刷や他の目的がある際、ライブラリ203によってデータベース119に保存されたデータと中間ファイルを生成することができる。そのようなオペレーションはインターフェース203からユーザがライブラリ203に対して指示をすることにより、可能である。作成された中間ファイルはネットワーク接続107から接続して、管理サーバー204やクライアント209に送信される。管理サーバー204もクライアント209も共に典型的なコンピューターである。管理サーバー204では、中間ファイルを受け取ると、中間ファイルをデータベース207に保存、管理する。管理された中間ファイルはインターフェーズ205を介して、ユーザが印刷、削除、検索などの指示をすることが可能である。印刷指示された中間ファイルは、ライブラリ206により印刷処理をされ、ネットワーク接続107を介してプリンター113に送信される。中間ファイルの管理が必要ないような場合には、単純にクライアント209に中間ファイルを送信し、ライブラリ210により印刷処理され、プリンター113に直接印刷される。<実施例1>上記で述べた、後付けデータの内容を考慮せず、単純にページ内に表が収まるところで行の分断を行うと、非常に見栄えの悪い表ができてしまうという課題を解決するための実施例を以下に述べる。本実施例の概要は、後付けデータの改行を考慮し、改行の無いところでは行の分断を行わないようにするものである。本実施例に従うことで、最終的には図9のように、後付けデータの内容を考慮しつつ行の分断を行うようになる。本実施例を説明するにあたり、新たに用語を定義する。図7の例で説明する。図7では後付けデータ701とフォーム702を用いてオーバレイしたときの例である。この例ではフォームには、1行に2つのセルが定義されている。ここで、表を構成する各行については、今後も単純に行と明記する。例えば図7では704を3行目と明記する。一方、1つのセル内で、後付けデータとして流し込まれたデータが、複数の行になる場合がある。図7の例では705、706、707に相当する。セル内で複数の行になる理由は、後付けデータ自体に改行が含まれている。後付けデータの長さがセルの幅よりも長く、データの途中で折り返すである。この場合のセル内の各文字列を、セル文字列と呼び、最後に行数を表す数字を付ける。図7の例では705はセル文字列1、706はセル文字列2、707はセル文字列3と呼ぶ。本実施例を図10、図11を用いて説明する。図11は本実施例のフローチャートである。図10は本実施例の具体例を示すもので、後付けデータ1001がセル1002に流しこまれた状態を示している。データを流しこんだ結果、セル文字列1からセル文字列5まで生成されている。以降では図11のフローチャートの流れに従い実施例を説明していく。なお、図11のフローチャートは、フォームと後付けデータがライブラリ203に渡され、ライブラリ203が後付けデータを解析してフォームに定義されてある表図形に格納していき、表がページ内に収まらず行の分断を行うところからスタートする。まずステップ1101では、ライブラリ203が、行の分断箇所を求める処理を開始する。次にステップ1102では、セル文字列nの高さを取得していく。そしてステップ1103でライブラリ203が、ステップ1102で取得したセル文字列nの高さを元に、そのセル文字列nがページ内に収まるかどうかを判定する。ここまでの処理の流れを図10の具体例を用いて説明する。図10のセル1002の例では、矢印1008の部分までが、ページ内の領域に収まるものとする。この場合、文字列A県B市、C県DD市、EEEEE県Fまではステップ1103でページ内に収まると判定される。FF市の文字列以降がページ内に収まらないと判定される。つまりセル文字列4以降がページ内に収まらないとされ、この時点ではn=4となる。ステップ1103でページ内に収まらないと判定された場合、ステップ1105でライブラリ203が、nの値を1引く。これは、図10の例では、3つ目のデータを以降のステップで使用するためである。ステップ1106では、ライブラリ203が、nが1以上かどうかを判定する。ステップ1106でnが1以上だと判定された場合、次にステップ1107で、ライブラリ203が、セル文字列nの最後が改行で終わっているかどうかを判定する。図10の具体例だと、セル文字列3のEEEEE県Fの文字列が判定対象である。ここでは最後が改行では終わっていないため、NOと判定される。ステップ1107でNOと判定された場合は、ステップ1105に戻る。これは図10の具体例でいうと、セル文字列2のC県DD市に対してステップ1106、ステップ1107を行うことになる。ステップ1108でYESと判定された場合は、ライブラリ203が、行の分断箇所を確定する。図10の具体例だと、分断候補1006では分断を行わず、分断候補1005で分断を行うことになる。以上の処理により、最終的には図9のように、後付けデータの内容を考慮しつつ行の分断を行うようになる。以上より、後付けデータの内容を考慮せず、単純にページ内に表が収まるところで行の分断を行うと、非常に見栄えの悪い表ができてしまうという課題が解決される。<実施例1の補足>実施例1では、後付けデータの改行を考慮し、改行の無いところでは行の分断を行わないことについて記載した。実施例1で説明した図10のステップ1106~1109の分断箇所判定処理は、必ず行ってもよいが、ユーザが補正処理を行うかどうか選択できてもよい。ユーザが選択する手段としては、エディタを使用してフォームを生成する際に、エディタに選択用のUIを設けることで、フォームに対してあらかじめ設定しておくことが考えられる。別の手段としては、ライブラリ203に補正の有無を指定できるインターフェースを設けることがある。オーバレイ印刷時にライブラリ203に対して、ユーザーが動的に補正の有無を指定することで、フォームを変更することなく帳票単位に補正処理の有無が選択できる。また、実施例1の例では改行の有無で分断箇所を判定したが、改行以外のコードを判定対象としてもかまわない。具体定期には句読点、や。などが考えられる。さらに、改行等の文字の種類だけではなく、文字の属性分断時に考慮することも考えられる。図12の具体例を用いて説明する。図12の後付けデータ1201の例では、後付けデータ内の11月12日というデータの前後に、c25500、cという文字列がある。これは11月12日という箇所だけを赤字で表示する、という命令を示している。これは既存技術の1つで、印刷アプリケーションが定めた記法に従って後付けデータを生成することで、特定の文字の属性をフォームの設定とは異なる属性で表示する技術である。この結果、オーバレイ印刷するとセル1204のように、11月12日だけ後付けデータ側で指定した色で表示される。ここで、11月12日という文字列だけをユーザがあえて通常とは異なる色で表示させているということは、この文字列をユーザが強調したいためである。そのため、この文字列の途中で行の分断を行ってしまうと、表の見栄えが損なわれることになる。このため、文字の属性が後付けデータ内で変更されている箇所がある場合は、改行のときと同様、行の分断を行わないようにする。<実施例2>実施例2では、セル文字列の数を考慮しながら、行の分断箇所を決定する例について記載する。実施例2は図13を用いて説明する。図13の1301、1302は、実施例2を実施しない場合のオーバレイ結果の1例である。1302を見ると、セル文字列が1つだけ次ページに送られてしまっている。この様に、最後のセル文字列のみを次ページに送るのは、表の見栄えが損なわれてしまう。これが実施例2の課題である。上記課題を解決するため、行の分断箇所を決定する処理内で、セル文字列の数を考慮するようにする。考慮した上でのオーバレイ結果の例が1303と1304である。1303と1304の例では次ページに送られるセル文字列が1個の場合は、行の分割を行わずに、3行目全体を次ページに送っている。セル文字列の数をどのように考慮するべきかは運用次第であるため、ユーザが任意に設定できるべきである。たとえば以下のような設定が考えられる。次ページに遅られるセル文字列がn個以下の場合は、行の分断は行わない次ページにセル文字列を送った結果、前ページのセル文字列がm行しか残らない場合は、行の分割を行わないセル文字列がX個以下の場合には、行の分断は行わない。上記のようにセル文字列の数を考慮して行の分断を行うことで、見栄えのよい帳票を生成することができる。<実施例2の補足>実施例2では表の見栄えを重視し、見栄えを損なわずに行の分断を行う例を記載した。ただ、表の見栄えを最重視した場合、そもそもどんなケースであっても行の分断を行わない、というケースも考えられる。しかし、どんなケースでも行の分断を行わない場合、別の課題が新たにでてくる。その課題を図14で説明する。図14の例では表の2行目で、セル文字列が10個表示される場合の例である。この2行目はページ内におさまらないため、行の分断を行わないのであれば、2行目全体を次ページに送ることになる。しかし、2行目自体がそもそもページに収まりきらないため、結局2行目を表示することができない。つまり、行の分断を行わなければ、オーバレイ印刷ができないことになる。解決案として、このようなケースの場合にのみ、表の分断を行うという判定をすることが考えられる。つまり、通常は行の分断は行わないが、図14の例のように、行の分断をおこなわなければオーバレイ印刷ができない場合にのみ行の分断を行うようにする。オーバレイ印刷がエラーになってしまうのであれば、表の見栄えよりも帳票の生成を重視する、という考え方である。これにより、表の見栄えを重視しつつも、オーバレイ印刷がエラーとなってしまうことを防ぐことができる。