(57)【要約】【課題】帳票フォームのレイアウトを簡単かつ的確に行う。【解決手段】帳票システム１０４は、ＸＭＬスキーマで記述された、構造を持つＸＭＬドキュメントに基づいて、表のレイアウトを作成する。まず、複合型の表要素があれば、そのフィールド名を確保し、そのフィールド領域内に、子の表要素を高さ方向に配置してレイアウトする。各子の表要素については、フィールド名とフィールド領域とがそれぞれ確保され位置とサイズが決定される。また、繰り返し要素については、当該表要素の下に、繰り返しを示す表要素を挿入する。作成されたレイアウトデータは、フォーム格納部１０３に保存される。【選択図】図１
2008052603.tif 000002
【特許請求の範囲】
【請求項１】
複数の表要素の順序及び階層により表の構造を記述した構造的記述データに基づいて、前記表要素の順序及び階層に従って各表要素の位置及びサイズを決定し、表のレイアウトを作成することを特徴とする表編集装置。
【請求項２】
複数の表要素の順序及び階層により表の構造を記述した構造的記述データを保存する構造データ保存手段と、
前記構造的記述データに基づいて、前記表要素の順序及び階層に従って各表要素の位置及びサイズを決定するレイアウト決定手段と、
前記レイアウト決定手段により決定された各表要素の位置及びサイズを保存するレイアウト保存手段と
を備えることを特徴とする表編集装置。
【請求項３】
前記構造的記述データにより記述された表の構造には、さらに、表要素が繰り返し表れることが記述され、
前記レイアウト決定手段は、繰り返される表要素については、繰り返されることを示す表要素を前記表に挿入し、その位置及びサイズを決定することを特徴とする請求項２に記載の表編集装置。
【請求項４】
前記表要素には、表中の項目の名称を示すフィールド名称と、項目の内容が挿入されるフィールド領域とが含まれ、
前記レイアウト決定手段は、前記複数の表要素の階層を、階層の親の表要素のフィールド領域内に、該親の表要素に従属する子の表要素を配置するように、表要素の位置及びサイズを決定することを特徴とする請求項２または３に記載の表編集装置。
【請求項５】
前記レイアウト決定手段により決定された表要素の位置及びサイズまたはそのいずれかを、ユーザの指示に応じて変更するレイアウト変更手段をさらに備えることを特徴とする請求項１乃至４のいずれか１項に記載の表編集装置。
【請求項６】
前記レイアウト変更手段は、ユーザの指示に応じて、前記親の表要素のフィールド名または前記子の表要素のフィールド名を削除する変更を施すことを特徴とする、請求項４を引用する請求項５に記載の表編集装置。
【請求項７】
前記レイアウト決定手段は、階層の等しい複数の表要素を、表の高さ方向に並列に配置するようにその位置及びサイズを決定し、
前記レイアウト変更手段は、ユーザの指示に応じて、前記階層の等しい表要素を、表の幅方向に配置するようにその位置及びサイズを変更することを特徴とする請求項１乃至６のいずれか１項に記載の表編集装置。
【請求項８】
前記レイアウト変更手段は、ユーザの指示に応じて、繰り返される表要素のフィールド名称を、ひとつにまとめて配置するよう、表要素の位置及びサイズを変更することを特徴とする、請求項３を引用する請求項４に記載の表編集装置。
【請求項９】
前記レイアウト変更手段は、ユーザの指示に応じて、繰り返される表要素の集計値を示す表要素を追加し、その表要素の位置及びサイズを決定することを特徴とする請求項３に記載の表編集装置。
【請求項１０】
コンピュータを、
複数の表要素の順序及び階層により表の構造を記述した構造的記述データを保存する構造データ保存手段と、
前記構造的記述データに基づいて、前記表要素の順序及び階層に従って各表要素の位置及びサイズを決定するレイアウト決定手段と、
前記レイアウト決定手段により決定された各表要素の位置及びサイズを保存するレイアウト保存手段と
して機能させることを特徴とするプログラム。
【請求項１１】
データ保存手段と、レイアウト決定手段と、レイアウト保存手段とを備えた表編集装置における表編集方法であって、
前記データ保存手段に保存された、複数の表要素の順序及び階層により表の構造を記述した構造的記述データに基づいて、前記レイアウト決定手段が、前記表要素の順序及び階層に従って各表要素の位置及びサイズを決定するレイアウト決定工程と、
前記レイアウト保存手段が、前記レイアウト決定工程により決定された各表要素の位置及びサイズを、前記データ保存手段へ保存するレイアウト保存工程と
を備えることを特徴とする表編集方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グラフィカル画面に図形を表示しながらその編集を行うことができる表編集方法及び表編集装置に関する。
【背景技術】
【０００２】
通知や依頼、許諾などを目的として、それら情報の受信者が、欲しい情報を明確化するために、情報の発信者が入力すべき項目（入力項目という）を配置した帳票フォームが利用される場合がある。発信者は入力項目に必要事項を入力した帳票フォーム（以下、記入済み帳票という）を紙媒体や電子的に受信者へ届ける。受信者は記入済み帳票を受け取り、その帳票の目的に応じて処理する。
【０００３】
このような帳票を用いた帳票システムを電子的に実現するためのソフトウェア製品（以下電子帳票システムという）、例えばｉｍａｇｅＷＡＲＥ（登録商標）  Ｆｏｒｍ  Ｍａｎａｇｅｒ（以下ｉＷＦＭ）などが存在する。このような電子帳票システムは、たとえばｉＷＦＭを例に取れば、処理ステップ別に複数のコンポーネントから成っている。
【０００４】
たとえば、受信者が帳票フォームを用意するステップは、編集コンポーネントが取り扱う。編集コンポーネントは、人がキーボードとマウスを使用して、コンピュータ画面上の帳票フォームに固定的な図形を描画したり、入力項目図形の場所やその書式を編集したりするものである。
【０００５】
発信者が帳票フォームに記入するステップは、発信者から入力情報を受け取るステップと、入力情報と帳票フォームから記入済み帳票を合成するステップと、記入済み帳票をディスプレイやプリンタなどのデバイスへ出力するステップの３段階に分けられる。最初のステップは入力解析コンポーネントが、２番目のステップは合成コンポーネントが、最後のステップは出力制御コンポーネントがそれぞれ取り扱う。
【０００６】
さて、電子帳票システムで扱われる帳票データを記述するために、ＸＭＬ（ｅＸｔｅｎｄｅｄ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）という記述言語が標準的に使われる。ＸＭＬは、タグと呼ばれる識別子とデータとで構成される。タグによってデータが区切られ、区切りに用いたタグと区切られたデータとは対応する。タグの意味や構造はユーザが定義できる。ＸＭＬで記述される文書の構造の定義は、たとえば「ＸＭＬスキーマ」などのスキーマ記述言語で記述される。なおＸＭＬスキーマは、Ｗ３Ｃにより勧告されたＸＭＬで記述した言語であり、http://www.w3.org/2001/XMLschemaにその名前空間が定義されている。
【０００７】
ＸＭＬは構造化可能であることが大きな特徴である。「構造化可能である」とは具体的には、以下のような属性を持つことを意味している。
・タグを階層化できること、
・タグの順序を定義できること、
・タグが必須のものかオプションであるか定義できること、
・タグの繰り返し可否とその最大回数および最小回数を定義できること。
【０００８】
さて、帳票フォームをＸＭＬで作成する場合、公開されたＸＭＬスキーマを参照することで、帳票フォームの作成を省力化できる。たとえば、ＸＭＬスキーマを読み込み、読み込んだＸＭＬスキーマで定義されたタグを、帳票フォーム上に配置可能な部品としてグラフィカルユーザインターフェースに一覧表示する帳票フォーム作成・編集ソフトがあった（たとえば、特許文献１等参照）。ユーザは、ＧＵＩに部品として表示されたタグをマウスのドラッグ＆ドロップ操作で帳票フォーム上の好きな位置に配置できる。
【特許文献１】特開平５−１３４８２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
この従来の帳票フォーム作成・編集ソフトによれば、ユーザは、帳票フォームの作成のために使用するＸＭＬスキーマを理解する必要がない。また、タグを用いて帳票フォームの部品を作成する必要もない。しかしながら、適切な部品を選択して的確に帳票フォームに配置するという、帳票フォームのレイアウト設計という手間のかかる作業はやはりユーザが行わねばならない。帳票フォームのレイアウト設計は、受信者が帳票を受け取った後スムーズに次の処理に移るには、入力情報がうまく分類・整理されて配置され把握しやすくなくてはならない。出力帳票は電子的に処理されるだけでなく、人間であるユーザに参照される場合も多く、帳票フォーム上の項目の配置が的確に分類・整理されていなければ内容の正しい把握が困難である。そして、適切に項目が配置された帳票フォームを設定するためには、設計者が相応の労力を費やす必要があった。また、人手による設計のために、項目が適切に配置されておらず、その内容を把握しにくい帳票フォームが作成されてしまうおそれもあった。
【００１０】
本発明は上記従来例に鑑みてなされたもので、帳票フォームのレイアウト設計の労力を軽減して、その生産性を向上させることを目的とする。また、帳票フォームの品質を向上させることを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するために本発明は以下の構成を有する。
【００１２】
複数の表要素の順序及び階層により表の構造を記述した構造的記述データに基づいて、前記表要素の順序及び階層に従って各表要素の位置及びサイズを決定し、表のレイアウトを作成する。
【００１３】
あるいは他の側面によれば本発明は以下の構成を有する。
【００１４】
複数の表要素の順序及び階層により表の構造を記述した構造的記述データを保存する構造データ保存手段と、
前記構造的記述データに基づいて、前記表要素の順序及び階層に従って各表要素の位置及びサイズを決定するレイアウト決定手段と、
前記レイアウト決定手段により決定された各表要素の位置及びサイズを保存するレイアウト保存手段とを備える。
【発明の効果】
【００１５】
本発明によれば、帳票フォームのレイアウト設計の労力を軽減して、その生産性を向上させることができる。また、帳票フォームの品質を向上させることができる。
【発明を実施するための最良の形態】
【００１６】
発明を実施するための実施形態を以下に説明する。
【００１７】
＜本発明を実施するシステム＞
図１は、本発明に係る電子帳票システムが稼働するコンピュータシステムの構成図である。プリンタ１０５を除く各ブロックはそれぞれ独立したコンピュータにより構成される。ここでは、コンピュータシステムをたとえば文房具通信販売会社の受注システムであるとする。ただしフォーム格納部１０３は、帳票システム１０４のコンピュータに接続されたストレージであってもよい。データベース１００は、商品や顧客のデータを格納している。業務システム１０１は受注システムの本体であり、ユーザのクライアント端末１０２にカタログを表示し、ユーザが発注すると、在庫確認、支払い処理などを行った後、注文書を作成する。クライアント端末１０２は、業務システム１０１にインターネット経由で接続されて、顧客が商品の発注を入力する。フォーム格納部１０３は、ＨＤＤのような記憶装置であり、各種の帳票フォームを格納している。その帳票フォームのうちの１つが注文書の帳票フォームである。帳票フォームはＸＭＬで記述されている。帳票システム１０４は、業務システム１０１から受注データを受信した後、フォーム格納部１０３から受注データに対応する帳票フォーム（受注フォーム）をダウンロードする。そして、帳票システム１０４は、受注フォームに受注データをオーバーレイして帳票データを生成し、プリンタ１０５に送信する。プリンタ１０５は、帳票システム１０４から送信された帳票データを印刷する。また帳票システム１０４は、既存の帳票フォームの編集や、新たな帳票フォームの作成を行うことができる。
【００１８】
さて、図１では業務システム１０１と帳票システム１０４とが１対１に対応している。これに対して、複数の業務システムで利用される帳票を単独の帳票システムで管理や作成するシステムを図２に示す。データベース２００は高性能なハードウェアに集約される。業務システム２０１は高性能な少数のハードウェアやブレードサーバのような比較的安価な多数の計算機をまとめたものに集約されて、多数のサービスが提供される。業務システム２０１は、他の業務システムとの互換性確保のために、たとえばＶＭＷＡＲＥ（登録商標）のような基盤仮想化技術で本来の基盤（プラットフォーム）とは異なる共通基盤でも動作する。また業務システム同士が通信して人手を省くために、各業務システムにフィルター・プログラムを覆い被せて、事実上の標準データ・フォーマットであるＸＭＬで通信できる。
【００１９】
帳票システム２０４は、例えばキヤノン製のｉｍａｇｅＷＡＲＥ（登録商標）  Ｆｏｒｍ  Ｍａｎａｇｅｒ（以下ｉＷＦＭ）で一元化されている。帳票システム２０４で管理および作成される帳票フォームも、やはりＸＭＬで記述される。図２の各構成要素と図１の各構成要素とは、業務システムの数が図２では複数となっている点で異なっているものの、その動作内容は共通している。
【００２０】
帳票システム１０４，２０４を構成するコンピュータは、プログラムを実行するＣＰＵ、プログラムやデータを格納するＲＡＭおよびハードディスク等のストレージ、業務システムに接続するためのネットワークインターフェースを持つ。実行されるプログラムには、フォーム編集プログラム１０４１が含まれる。またＲＡＭやハードディスクに格納されるデータには、受注フォームを定義したＸＭＬスキーマ３００あるいは帳票フォームデータ１０３２が含まれる。ＣＰＵによりフォーム編集プログラム１０４１を実行することで、帳票フォームデータ１０３２を作成できる。
【００２１】
＜受注フォームの構造＞
図３は、フォーム格納部１０３，２０３に格納された受注フォームを定義したＸＭＬスキーマ３００を示す。図３ではＸＭＬ宣言及びルート要素は省略した。これによると、受注フォームは、図４のような階層構造と繰り返しを持たなければならない。「注文」データ４０１は、「発注日」４１１、「発注者」４１２、「注文項目」４１３、「送付先」４１４から構成される。「発注日」４１１はdate（日付）型のデータであり、発注の年月日を表す。「発注者」４１２はstring（文字列）型のデータであり、発注者の名前を表す。「注文項目」４１３は注文項目型のデータであり、注文内容の１つを表す。注文項目型は別途定義されている。また、「注文項目」４１３は繰り返し定義と繰り返しの最小個数、最大個数が定められていて、１個〜９個の「注文項目」４１３が「注文」４０１には含まれていなければならない。「送付先」４１４はaddress（アドレス）型のデータであり、商品の送付先を表す。「発注日」４１１，「発注者」４１２，「注文項目」４１３，「送付先」４１４はこの順番に並んでいなければならない。
【００２２】
注文項目型は、「商品名」４２１，「個数」４２２，「単価」４２３からなる。「商品名」４２１はstring型のデータであり、商品の名称を表す。「個数」４２２はpositiveInteger（正の整数）型のデータであり、商品の個数を表す。「単価」はdecimal（小数）型のデータであり、商品１つあたりの価格を表す。「商品名」４２１，「個数」４２２，「単価」４２３はこの順番に並んでいなければならない。
【００２３】
受注フォームのＸＭＬスキーマ３００は、図４の定義を満たすように記述されている。なお図３においては、ＸＭＬスキーマでは通常付されるために省略されたＸＭＬ宣言により、ＸＭＬスキーマの名前空間を表す名前空間接頭辞ｘｓｄが定義されている。すなわち要素名の先頭にｘｓｄ：とつく要素は、ＸＭＬスキーマの要素である。なお、図３の要素はすべてＸＭＬスキーマの要素であるので、以下の説明では、各要素について「ＸＭＬスキーマの」という修飾は省略する。
【００２４】
さて、コンプレックスタイプ要素は、子要素または属性を持つ要素のデータ型を表している。図４の注文４０１は複数の子要素を持つので、図３においては、注文４０１は、「注文」というｎａｍｅ属性を持つＸＭＬスキーマのコンプレックスタイプ要素３０１により表される。シーケンス要素は、子要素の順序をその並び順で指定する要素である。図３においては、注文４０１の子要素である発注日４１１〜送付先４１４は、図４の順序でなければならない。そこで、これら子要素をシーケンス要素３０２で括ることで、その順序が固定される。
【００２５】
注文項目４１３を除く各子要素は子要素を持たないので、エレメント要素により定義される。すなわち、発注日３１１は、ｎａｍｅ属性として「発注日」、ｔｙｐｅ属性としてｄａｔｅを持つエレメント要素３０３により表される。ｔｙｐｅ属性の値ｄａｔｅにも名前空間接頭辞ｘｓｄが付されており、ＸＭＬスキーマで定義されていることが分かる。
【００２６】
発注者４１２，注文項目４１３，送付先４１４についても、同様にエレメント要素３０４，３０５，３０６を用いて記述されている。ただし、注文項目４１３は子要素として商品名４２１，単価４２２，個数４２３を持つので、コンプレックス要素３０７により「注文項目」型として別途定義されている。また、注文項目を定義したエレメント要素３０５には、そのエレメント要素３０５の最小個数及び最大個数をそれぞれ示すｍｉｎＯｃｃｕｒｓ属性およびｍａｘＯｃｃｕｒｓ属性が記述されている。
【００２７】
注文項目４１３を定義したコンプレックスタイプ要素３０７では、注文４０１と同様に、子要素の順序をシーケンス要素３０８により定義される。また、商品名４２１，単価４２２，個数４２３を示す各子要素がエレメント要素３０９，３１０，３１１で記述されている。なお本実施形態では、ＸＭＬスキーマに含まれる各要素をデータ要素と呼ぶ。
【００２８】
このように、フォームはＸＭＬスキーマにより、その構造も含めて記述される。すなわち、構造には、フィールド間の順序及び親子関係、フィールドの繰り返しといった要素を含む。
【００２９】
＜フォーム作成手順＞
（解析処理）
受注フォームのＸＭＬスキーマ３００から帳票フォームを自動作成すべく、ｉＷＦＭのフォーム編集プログラムはＸＭＬスキーマ３００を読み込む。フォーム編集プログラム１０４１は、帳票システム１０４，２０４で動作する。図５のような構成になっている。以下、この構成に沿って動作を説明する。
【００３０】
フォーム編集プログラム１０４１が読み込んだＸＭＬスキーマは、ＸＭＬスキーマ解析部５０１で解析される。解析結果は表フィールド自動生成部５０２に渡されてメモリ上に格納される。
【００３１】
その際、ＸＭＬスキーマ解析部５０１ではまず、ＸＭＬスキーマ３００はデータの構成要素ごとに分解される。そしてＸＭＬスキーマ３００に含まれるデータ要素は、データ要素の名前の文字列を持つ「フィールド名称」という固定的なフォーム要素（表要素とも呼ぶ）と、データ要素の実体を格納する「フィールド領域」という可変的なフォーム要素に分解される。たとえば、フォーム要素は、固定的な値を持つ場合にはその値を持つデータとしてメモリに保存される。また、可変的なフォーム要素は、データ型とデータ型に応じたサイズの領域としてメモリに保存される。フォーム要素とは、帳票フォームを構成する要素であり、入力されるデータの項目名や、入力されるデータそのものが保存される個々の領域である。またフィールドとは、帳票フォーム中で入力データによりオーバーレイされる個々の項目を指す。
【００３２】
ＸＭＬスキーマ解析部５０１は、各データ要素が単純型か複合型かを判別する。単純型とは、数値または文字列を表す。複合型とは、１個以上の単純型あるいは複合型をまとめてひとつの型としたもので、たとえばコンプレックスタイプ要素により記述されている。また、データ要素が複合型であれば子要素の数と子要素にさらに複合型を含むか否かが判別される。判別結果は、フィールド属性として、フィールド名称およびフィールド領域に対応付けてメモリ等に保存される。保存されたフィールド属性は、表フィールド自動生成部５０３に渡される。また、フィールド属性には、次のフィードへのポインタ、子フィールドであれば親フィールドへのポインタ、および複合型であれば子フィールドへのポインタを含む。これにより、順次計算することを可能にしている。フィールド名称およびフィールド領域およびフィールド属性は、帳票フォーム上のフィールドごとに１組定義される。これらをまとめてフィールドあるいはフィールド定義データと呼ぶ。
【００３３】
さて、上記解析処理を、図６乃至図８で具体的に説明する。図３のＸＭＬスキーマ３００の文字列をＸＭＬスキーマ解析部５０１は順次読み、まずコンプレックスタイプ要素３０１が読み込まれる。この要素３０１のｎａｍｅ属性からフィールド名称というフォーム要素が作成される。フォーム要素は「注文」という値を持つ。要素３０１は、コンプレックスタイプ要素であって、子要素として要素３０３〜３０５を有する複合型の要素である。したがって、フィールド領域として、要素３０３〜３０５それぞれのデータ型をその順に収める領域が確保される。
【００３４】
次にシーケンス要素３０２が読み込まれる。シーケンス要素は子要素の順序を規定するための要素であるから、シーケンス要素間に挟まれるエレメント要素を読み込んだなら、その要素の順序は、その並び順に固定される。そのためたとえば要素の並び順が、図８に示すポインタによりフィールド属性に含まれる情報として記憶される。
【００３５】
エレメント要素３０３が読み込まれると、そのｎａｍｅ属性からフィールド名称というフォーム要素が作成される。またｔｙｐｅ属性からデータ型ｄａｔｅのデータを格納するフィールドというフォーム要素が作成される。また、この要素はその属性から単純型であり、「単純型」を示すフィールド属性データが作成されて、表フィールド自動生成部５０３に渡される。図６にこの様子を示す。図６には、フィールド定義データ６０１が示されている。要素３０４，３０６については、属性の値は異なるものの、要素３０３と同じ要領で処理される。
【００３６】
要素３０５についても同様であるが、データ型「注文項目」は、要素３０５の読み込み時点で未定義であり、フィールド名称以外のフォーム要素の作成は保留される。
【００３７】
この後コンプレックスタイプ要素３０７を読み込んだ時点で、ｎａｍｅ属性の値から、この要素３０７が注文項目を定義していると判定できる。そこで、「注文項目」というフィールド名称を持つフィールドは複合型であり、コンプレックスタイプ要素３０７の子要素３０８〜３７０の数が３であるから、子要素数は３となる。また、子要素はいずれも単純型であり、複合型の子要素はないと判定できる。これら判定結果から、フィールド「注文項目」のフィールド属性は、複合型、子要素数３、複合型子要素なし、であることを示す値となる。また、「注文項目」のフィールド領域として、ｓｔｒｉｎｇ型と、ｐｏｓｉｔｉｖｅｉｎｔｅｇｅｒ型と、ｄｅｃｉｍａｌ型のフィールド領域をこの順序で並べたフォーム要素が作成される。この様子を図７に示す。図７には、フィールド定義データ７０１が示されている。
【００３８】
図８には、ＸＭＬスキーマ３００に記述された要素の親子関係を、受注フォーム上のフィールド間の親子関係として示す構造の一例を示す。フィールド属性には上述した情報の他、図８のようなポインタが記述される。図３のＸＭＬスキーマ３００により、ＸＭＬスキーマ解析部５０１は、データ要素３０３〜３０６がデータ要素３０１の子要素であり、データ要素３０９〜３１１がデータ要素３０５の子要素であると判定できる。さて、ポインタ８２１は、親要素に対応するフィールド間の順序を表す。図８では、親フィールド８０１の直後には親フィールド８０２が続くことがポインタ８２１で示される。すなわち、シーケンス要素内で記述されたエレメント要素から生成されるフィールドは、ポインタ８２１により順序づけられる。これは子要素についても同様であり、図８ではポインタ８１２によりフィールド間の順序づけが定義される。
【００３９】
ポインタ８２２は親フィールドから子フィールドへのポインタである。子フィールドが複数ある場合には、個々の子フィールドヘのポインタが保持される。逆に子フィールドから親フィールドへのポインタ８２３も保存される。これらポインタは、それぞれＸＭＬスキーマの親要素と子要素とに対応する親フィールド及び子フィールド間を接続するデータとして生成される。各ポインタは、たとえば、メモリに保存された各フィールドのアドレス、特にフィールド属性のアドレスを、指し示す。
【００４０】
したがって、図３のＸＭＬスキーマに対応するフィールド属性においては、要素３０１のフィールド属性に、その子要素３０３〜３０６に対するポインタが記録され、要素３０５のフィールド属性に、その子要素３０９〜３１１に対するポインタが記録される。またその逆方向のポインタも各子要素のフィールド属性に記録される。また、シーケンス要素で定義された順序を示すポインタも、各レベルの要素間で定義される。
【００４１】
ＸＭＬスキーマの解析とその結果（フィールド名、フィールド領域、フィールド属性）の格納が完了したら、次の自動配置処理に進む。
【００４２】
（自動配置処理）
表フィールド自動生成部５０２の生成結果に基づき、表フィールド自動配置部５０３が自動配置処理を実施する。その処理のフローチャートを図９に示す。
【００４３】
図９の処理は再帰的処理である。処理の途中で複合型が現れる毎に図９の処理が再帰呼出しされる。そうすることですべての単純型まで下って処理を行い、遡って次の処理を実施するという繰り返しにより、全体的に処理が行われる。ＸＭＬスキーマにおける親要素と子要素の関係はフィールド定義データにおいても反映されている。そこで以下の説明では、親要素と子要素とに対応するフィールド定義データをそれぞれ親フィールドと子フィールドと呼ぶ。
【００４４】
最初、上位プログラムから帳票フォームの開始位置と幅を指定してこの自動配置処理は呼び出される（Ｓ９０１）。たとえば、初期的には、ユーザが予め入力しておいた開始位置と幅とが、ステップＳ９０１で表フィールド自動配置部５０３に引き渡される。また再帰的に呼び出される場合には、呼び出し時のパラメータが引き渡される。これらをまとめて上位指定の開始位置および幅と呼ぶ。すると、表フィールド自動配置部５０３は、各フィールドのフィールド名称とフィールド領域の幅とそれぞれの横方向の開始位置を計算する（Ｓ９０２）。具体的には、現在の階層のフィールド名称およびフィールド領域のデータ型をすべて洗い出し、それぞれが妥当な表示となるように、上位指定の幅をフィールド名称とフィールド領域に割り当てる。ただし、現在のフィールドが複数ある場合には、そのうちもっとも文字数の多いフィールド名称がフィールド名称の幅の基準となる。たとえば、現在の階層のフィールド名称に文字数×所定長（１文字あたりの幅）を割り当て、残りを現在の階層のフィールド領域に割り当てる。
【００４５】
現在階層のフィールド名称の横方向の開始位置は、上位指定の開始位置に一致する。そして、フィールド名称の幅をフィールド名称の開始位置に加算して、フィールド領域の横方向の開始位置を計算する（図１０）。
【００４６】
次に、フィールド名称とフィールド領域の縦方向の開始位置を計算する（Ｓ９０３〜Ｓ９１２）。Ｓ９０３およびＳ９１２は、その間の処理を条件にしたがって繰り返し実行することを意味する。
【００４７】
現在計算中のフィールドが現在の階層の最初のフィールドか判定する（Ｓ９０４）。もしそうであれば、上位指定の縦方向の開始位置が、そのフィールド名称とフィールド領域の縦方向の開始位置とする（Ｓ９０５、Ｓ９０７）。決定されたフィールド名称及びフィールド領域の位置や幅は、たとえばフィールド属性の一部として、フィールドに関連づけてたとえばフォーム格納部１０３，２０３に保存される。これは他の値についても同様である。もし、現在計算中のフィールドがこの階層の最初のフィールドでなければ、ひとつ前のフィールドの縦方向開始位置から一つ前のフィールドの高さ分下方向にずらした位置を計算する。その位置が、そのフィールド名称とフィールド領域の縦方向の開始位置として保存される（Ｓ９０６、Ｓ９０７、図１１）。
【００４８】
次に、フィールド名称とフィールドの高さとを計算する。まずフィールドが単純型であるか判定する（Ｓ９０８）。もしそうであれば、あらかじめ定めた規定の高さ、あるいはユーザに指定された高さがそのフィールドの高さとなる（Ｓ９０９）。一方、フィールドが複合型であれば、Ｓ９０７で求められた現在のフィールドの開始位置と幅とを上位指定の開始位置及び幅として与え、再帰的に図９の自動配置処理を呼び出す（Ｓ９１１）。これにより複合型のフィールドに属する子フィールドについても、現在のフィールド内にレイアウトする（図１２）。
【００４９】
ここまでの処理を同一階層のフィールドに対して繰り返しておこない、各フィールド名称と各フィールド領域の開始位置、高さ、幅を確定する。それらはフィールドごとに関連づけられて保存される。そしてフィールドの高さを合計して、上位の呼び出し元にその複合型の高さとして返す。
【００５０】
（繰り返しがある場合の処理）
ここまで述べた解析処理と自動配置処理は階層構造のみを含み繰り返しがない場合であったが、ここでは、繰り返しを含む処理について図１４を参照して説明する。図１４では、図９と共通するステップについての説明は省略する。
【００５１】
ＸＭＬスキーマで繰り返しが定義されたデータ要素がある場合、表フィールド自動生成部５０２は、そのデータ要素に対応するフィールド属性に繰り返しフラグを立てる。表フィールド自動配置部５０３ではフィールド属性中の繰り返しフラグを参照し（Ｓ１４０１）、そのフィールドを配置する際に高さを一定の値だけ増やす（Ｓ１４０２）。この繰り返しフィールドをＦＭエディタで表示する場合には、フィールド名称やフィールド領域の下方に、増えた高さ分の矩形を設け、その矩形内に繰り返しを表す記号を表示する。こうしてユーザに繰り返しが定義されたフィールドであることを明示する。
【００５２】
（出力）
図９あるいは図１４の手順で表フィールド自動作成配置部５０３が動作した結果、フィールド名称とフィールドが自動生成・自動配置されて、それらの位置とサイズが決まる。決定された表要素（フィールド名称及びフィールド領域）の位置及びサイズは、フォーム格納部１０３，２０３に、レイアウトデータとして保存される。レイアウトデータに従って、たとえな罫線を描き、フィールド名称とフィールド領域の値をそれぞれの位置及びサイズにしたがって表に挿入する。すなわち、表をレイアウトすると、図１３のような表１３０１が生成される。作成された表１３０１は、フォーム表示部５０４（図５参照）によりフォーム編集プログラム１０４１の画面に表示される。
【００５３】
また、繰り返しのある場合の自動配置の結果は図１５の表１５０１のようになる。図３のＸＭＬスキーマ３００では繰り返しが定義されているから、ＸＭＬスキーマ３００からは表１５０１が作成されて表示される。繰り返しを示す記号１５０２が、繰り返しフィールドの直下に表示されている。図１５の表を持つ帳票フォームに、注文書システムのＸＭＬスキーマに適合した図１６のＸＭＬデータ１６０１を流し込むと、図１７の帳票データが完成する。
【００５４】
図１７において、各タグは、帳票フォームにおけるフィールド名称と対応する。フィールド名称と一致する名称のタグに記述されたデータが、当該フィールド領域に挿入される。たとえば、図１６のＸＭＬデータ１６０１は、クライアント端末において、受注システムで提供するＷｅｂページ上で入力され、帳票システム１０４，２０４に引き渡される。そして帳票システム１０４，２０４が、フォーム編集プログラム１０４１で作成された帳票フォームに、業務システムから受け取った値を、フィールド名とタグ名との同一性に基づいて合成する。
【００５５】
以上のようにして、ＸＭＬスキーマで、帳票フォームのフィールド名称とフィールド領域のデータ型および順序と繰り返すの有無を定義しておけば、各フィールド名称とフィールド領域とに適切な幅と高さとが割り当てられ、レイアウトされる。レイアウトされた位置及び幅は、フィールドごとにたとえばフィールド属性として保存される。帳票フォームの表示や印刷時には、フィールド属性を参照して、そこに記録された位置や幅に従ってフォームが再構成される。このため、作業者は、各フィールドを定義するだけでレイアウトに関して労力を費やす必要がない。また、作成された帳票フォームのレイアウトは、元のＸＭＬスキーマで定義された各フィールドの並びや親子関係を反映した、直感的に内容を把握しやすいものとなる。
【００５６】
［第２実施形態］
図９および図１４の手順で帳票フォームがＸＭＬスキーマから自動生成された。しかし、なにぶん自動配置であるので、ユーザがそのレイアウトを気に入るとは限らない。そこで本実施形態ではさらに、表フィールド切り替え編集部５０５により帳票フォームを編集できる。そのためには、表示された帳票フォーム上で、編修対象とするフィールド名称やフィールド領域をユーザがたとえば右クリックする。なお、本実施形態のシステム構成は第１実施形態と同様である。したがって、操作や動作の例、フローチャートに限って本実施形態では説明する。またフィールド属性には、親フィールド名称表示フラグ、子フィールド名称表示フラグ、横並びフラグ、まとめ表示フラグという４つのフラグが、第１実施形態のフィールド属性に追加される。集計については、処理命令であるので、フラグは持たない。親フィールド名称表示フラグがセットされていれば、複合型要素に対応する親フィールド名称が表示される。子フィールド名称表示フラグがセットされていれば、複合型要素に属する子要素に対応する子フィールド名称が表示される。横並びフラグがセットされれば、当該フィールド名称及びフィールド領域は、同一階層のフィールドと横並びに表示される。まとめ表示フラグがセットされれば、繰り返されるフィールドのフィールド名称が一括して表示される。集計命令が指示されれば、帳票フォームの下欄に集計行が追加される。なお、上述の説明では「表示」としているが、本実施形態では各フラグの値に応じて帳票フォームのデータそのものが編集し直される。これは以下の説明についても同様である。
【００５７】
さて、ユーザが上述のように、ユーザインターフェースに表示された帳票フォーム上のあるフィールドを右クリックをすると、フォーム編集プログラム１０４１はその位置に対応するフィールドのフィールド属性を参照する。そして、フィールドの型（単純型または複合型）と、複合型であれば、その子フィールドに単純型のみを含むか否か、また繰り返しフィールドであか否かを判定する。そして判定結果に応じたレイアウト切り替え用メニューを表示する。レイアウト切り替え用メニューには、上述した親フィールド名称表示フラグ、子フィールド名称表示フラグ、横並びフラグ、まとめ表示フラグ、集計命令それぞれに対応する項目が表示される。また、指示されたフィールドのフィールド属性に保持された各フラグの値が、メニュー項目ごとにチェックマークで表示される。
【００５８】
図１８に表示される簡単レイアウト切り替え用のメニューの一例を示す。図１８は、現在指示された位置が、複合型のフィールド領域であり、その子フィールドは全て単純型であり、しかも繰り返しがない場合に表示される。図１８のメニューのうち、上２個の項目１８０１，１８０２は複合型フィールドであることに由来する項目である。真ん中の１個の項目１８０３は複合型フィールドでありかつ子フィールドに単純型のみを含むことに由来する項目である。下２個の項目１８０４，１８０５は繰り返しフィールドであることに由来する項目である。図１８においては、条件に該当する項目は、左端にチェックマークが付されている。指示されたフィールドに由来しないフラグ（たとえば単純型のフィールドについて項目１８０１，１８０２など）は、表示しても良いが表示しない方が望ましい。各フラグは、ユーザの操作によりその値をメニューから変更できる。以下、メニュー項目に関連付けて、その項目を選んだ場合の動作を説明する。
【００５９】
（「親フィールド名称を表示する」選択（セット）時の動作）
デフォルトではこのオプション（親フィールド表示フラグ、フラグをオプションともいう）は活性化（セット）されている。表フィールド切り替え編集部５０５によりこのオプションが切り替えられると、表フィールド自動配置部５０３が起動されて、図１９のようにレイアウトが変化する。これは他のオプションについても同様である。図１９の例では、「注文項目」という複合型のフィールドのフィール属性の親フィールド表示フラグが、セットされた状態１９０１からリセットされた状態１９０２へと操作されている。
【００６０】
オプションを切り替えたとき、フォーム編集プログラム１０４１により、当該帳票フォームの部分的な自動配置処理が行われる。まず、指示された、データ型が複合型のフィールド（複合型フィールドという）の親フィールド名称表示フラグを非表示に設定（リセット）する。その設定に基づき、表フィールド自動配置部５０３は、複合フィールドのフィールド領域の開始位置を親フィールド名称の開始位置へシフトする。それとともに、複合フィールドのフィールド領域の幅に親フィールド名称の幅を加算する。そして、複合フィールドのフィールド領域内のレイアウトの再帰処理には、そのフィールド領域の開始位置と幅とを指定する（図２０）。これによりフィールドの幅が変更になるので、フィールド領域内のデータに折り返しが設定されていた場合には高さが変わることがある。変更対象の複合型フィールドの高さが変わった場合には、それより下のフィールドについて開始位置を変更してレイアウトを調整する。本機能を含む場合のフローチャートを図２１に示した。
【００６１】
図２１において、図１４と共通のステップには同一の符号を付した。図１４との相違点に付いてのみ説明する。
【００６２】
ステップＳ２１０１では複合型か否かフィールド属性を参照して判定する。複合型であれば、ステップＳ２１０２で親フィールド名称表示フラグをテストする。セットされていなければＳ２１０３で、指定されている描画幅全体をフィールド領域に割り当てる。この後あるいは上記条件のいずれかに合致しない場合にはＳ９０２に分岐する。また、レイアウト決定後、フォーム表示部５０４でフォームを表示する際に、親フィールド表示フラグがセットされていない親フィールドのフィールド名称は表示されない。これは印刷時にも同じである。
【００６３】
（「子フィールド名称を表示する」選択時の動作）
デフォルトではこのオプション（子フィールド名称表示フラグ）は活性化されている。このオプションを切り替えることで、図２２のようにセットされた状態２１０１からリセットされた状態２１０２へレイアウトが変化する。オプションを切り替えたとき、フォーム編集プログラム１０４１により部分的な自動配置処理が行われる。まず、該当の複合型フィールドの子フィールド名称を非表示に設定する。その設定に基づき、表フィールド自動配置部５０３は上位からの指定幅をフィールド名称とフィールドに割り振る処理を止めて、フィールド名称の幅を０とし、フィールドの幅を上位からの指定幅とする。本機能を含む場合のフローチャートを図２３に示した。
【００６４】
図２３において、図１４と共通のステップには同一の符号を付した。図１４との相違点に付いてのみ説明する。
【００６５】
ステップＳ２３０１では子フィールドか否かをフィールド属性を参照して判定する。子フィールドであれば、ステップＳ２３０２で子フィールド名称表示フラグをテストする。セットされていなければＳ２３０３で、指定されている描画幅全体をフィールド領域に割り当てる。この後あるいは上記条件のいずれかに合致しない場合にはＳ９０２に分岐する。また、レイアウト決定後、フォーム表示部５０４でフォームを表示する際に、子フィールド表示フラグがセットされていない子フィールドのフィールド名称は表示されない。これは印刷時にも同じである。
【００６６】
なお本実施形態では各オプションは独立して説明されている。しかし、たとえば子フィールドであると共に親フィールドであるようなフィールドも存在する。この様なフィールドについて、親フィールド表示フラグと子フィールド表示フラグとが矛盾する設定をされた場合、いずれかのフラグが優先され、矛盾する他方の設定は無視される必要がある。
【００６７】
（「並び方向を横にする」選択時の動作）
デフォルトではこのオプションは不活性化されている。このオプションを切り替えることで、図２４のように、縦並びのレイアウト２４０１から横並びのレイアウト２４０２へレイアウトが変化する。図２４は、複合型フィールドの子フィールドについて横並びとした例である。
【００６８】
オプションを切り替えたとき、フォーム編集プログラム１０４１により部分的な自動配置処理が行われる。まず、指定されているフィールドと同一階層の各フィールドのフィールド名称の文字数とフィールド領域の型から、割り当てられた幅を各フィールドに割り当てる。たとえば、上位から指定された幅を同一階層のフィールド数で割り、１フィールドあたりの幅を決定する。そして個々のフィールドについては、フィールド名称とフィールド領域のうち幅が大きい方を選択し、その値を、前に決定した１フィールドあたりの幅とを比較する。前に決定した１フィールドあたりの幅の方が大きければ、その値が各フィールドの幅となる。一方、フィールドごとに決定した幅の方が大きければ、当該フィールドについては大きい方の幅とする。そして他のフィールドの幅をその分狭くする。
【００６９】
次に、各フィールドの幅ずつ右にシフトしながら、各フィールド名称の位置を計算する。すなわち、開始位置に割り当てられた幅を積算していくことで、各フィールドの幅方向の開始位置が決定される。次に、各フィールドのフィールド名称から規定の高さだけ下にシフトしてフィールド領域の位置を計算する。次に、各フィールドの高さを規定の高さとする。フィールド名称の高さとフィールドの高さを合計し、呼び出し元に返す。
【００７０】
この処理で複合フィールドの高さが変化するので、変更対象の複合型フィールドの高さが変わった場合には、それより下のフィールドについて開始位置を変更してレイアウトを調整する。
【００７１】
本機能を含む場合のフローチャートを図２６に示した。図１４と共通するステップは同じ符号を付した。ステップＳ２６０１において、縦並びであるか否かフラグを参照する。縦並びなら従来通り、Ｓ９０２〜Ｓ９１３の処理を行う。横並びの場合には、上述した処理をＳ２６０２〜Ｓ２６０６で実行する。なお、図２６では、横並び指定されたフィールドが複合型である場合が考慮されていない。もしこれを考慮するのであれば、Ｓ２６０４の直後に、Ｓ２６０５及びＳ２６０６に代えて、図１４のＳ９０８以降を実行すればよい。もちろんＳ９１１で再帰的に呼び出される手順は図２６の手順である。
【００７２】
（「項目名をまとめて表示する」設定時の動作）
デフォルトではこのオプションは不活性化されている。このオプションを切り替えても、フォーム編集時のレイアウトは変化しない。このオプションはフォームにＸＭＬデータを流し込んだときに繰り返しデータ要素に複数個のデータが入っているとはじめて有効に働く。図２７に本オプションを活性化したフォームにＸＭＬデータを流し込んだ例を示す。繰り返しフィールドである注文項目のフィールド名称「注文項目」が、繰り返し数の２個ではなく１個だけ表示され、間の罫線も表示されなくなる。
【００７３】
オプションを切り替えたとき、内部ではフィールド名称に、まとめ表示属性をつけている。ＸＭＬデータを流し込んで帳票データを生成するときにまとめ表示属性のある繰り返しフィールドを見つけると、繰り返しの２回目以降はフィールド名称を表示せず、またフィールド名称を区切る罫線を引かないように動作する。
【００７４】
（「集計行を追加する」設定時の動作）
このメニュー項目はオプションではなくコマンドである。このコマンドを選択すると、繰り返し要素の下に集計用行を追加する。
【００７５】
このコマンドを選択したとき、フォーム編集プログラム１０４１により部分的な自動配置処理が行われる。まず、該当の繰り返しフィールドのフィールド属性に集計行追加属性が設定される。その設定に基づき、自動配置ルーチンは、繰り返しフィールドの繰り返しを表す記号（図１８の記号２８０１）の下に集計行（図１８の記号２８０２）を配置する。集計行は、集計行名称と集計行フィールドからなるが、追加直後はどちらも空であるので、表示上は入力を促すメッセージが表示される。集計行名称には一般的な文字列を入力できる。集計行フィールドには文字列を入力するのだが、それは式になっている必要がある。式とは、繰り返しデータ要素の子要素などを表す変数と、単一や複数の変数の演算を行う関数から構成される。ＸＭＬデータを流し込んだときに式の値が定まり、その値が表示・印刷される。
【００７６】
（出力）
本実施形態のシステムによる出力は、ユーザが選択したメニュー項目に基づき生成される変更後のフィールド配置や、運用時に有効となる属性の設定である。フィールド属性が元となるデータの構造情報を保持しているために、同種の一般的なグラフィック・エディタに比べて少ない操作でこの出力を得ることができるのが特徴である。
【００７７】
以上のようにして、ＸＭＬスキーマで、帳票フォームのフィールド名称とフィールド領域のデータ型および順序と繰り返すの有無を定義しておけば、各フィールド名称とフィールド領域とに適切な幅と高さとが割り当てられ、レイアウトされる。レイアウトされた位置及び幅は、フィールドごとにたとえばフィールド属性として保存される。帳票フォームの表示や印刷時には、フィールド属性を参照して、そこに記録された位置や幅に従ってフォームが再構成される。このため、作業者は、各フィールドを定義するだけでレイアウトに関して労力を費やす必要がない。また、作成された帳票フォームのレイアウトは、元のＸＭＬスキーマで定義された各フィールドの並びや親子関係を反映した、直感的に内容を把握しやすいものとなる。
【００７８】
＜請求項との対応＞
ここで、出願当初明細書に記載された各手段と明細書記載の構成との対応を説明する。
【００７９】
「複数の表要素の順序及び階層により表の構造を記述した構造的記述データ」は、たとえばＸＭＬスキーマで記述した表の構造を示すデータであり、たとえば図３に示す。
【００８０】
「前記表要素の順序及び階層に従って各表要素の位置及びサイズを決定し、表のレイアウトを作成する」ことは、帳票システムが行い、特に表フィールド自動生成部５０２及び表フィールド自動配置部５０３に対応する。
【００８１】
「複数の表要素の順序及び階層により表の構造を記述した構造的記述データを保存する構造データ保存手段」は。フォーム格納部１０３，２０３に対応する。
【００８２】
「前記構造的記述データに基づいて、前記表要素の順序及び階層に従って各表要素の位置及びサイズを決定するレイアウト決定手段」は、帳票システム、特に表フィールド自動生成部５０２及び表フィールド自動配置部５０３に対応する。
【００８３】
「前記レイアウト決定手段により決定された各表要素の位置及びサイズを保存するレイアウト保存手段」は、帳票システム、特に表フィールド自動生成部５０２及び表フィールド自動配置部５０３に対応する。またその保存先はフォーム格納部１０３，２０３に対応する。
【００８４】
「前記レイアウト決定手段により決定された表要素の位置及びサイズまたはそのいずれかを、ユーザの指示に応じて変更するレイアウト変更手段」は、表フィールド切り替え編集部５０５および表フィールド自動配置部５０３に対応する。
【００８５】
［他の実施形態］
本実施形態では、ＸＭＬスキーマで記述されたデータから帳票フォームを生成した。これに対してＸＭＬスキーマ以外の言語でや記述方法であっても、その構造を記述するものであれば、それを基にして帳票フォームを生成することができる。このような記述を、フォームの構造的記述と呼び、そのデータを構造的記述データと呼ぶことにする。ＸＭＬスキーマは構造的記述のための一方法であり、それにより記述されたフォームの構造は構造的記述データである。
【００８６】
また帳票フォームをお、表というより一般的なものに置き換えて本発明を適用することもできる。
【００８７】
また、第２実施形態に示したオプションは、フローチャートではそれぞれ独立した機能として説明した。しかし、もちろんこれら全てを併せ持つシステムとすることもできる。もしも矛盾する設定がされた場合には、いずれかの設定を優先するか予め決めておけばよい。
【００８８】
さらに本実施形態では、フィールド名称の出力に有無や配置の方向、集計行の有無、繰り返し項目のまとめといった、変更される頻度が高いフォーム要素に関して、ユーザが簡単に変更することができる。このため一層利用上の利便性が向上し、編集時の生産性が向上する。また、帳票フォームの自由度を高めることができる。
【００８９】
なお本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。また本発明の目的は、前述の実施形態の機能を実現するプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータが記憶媒体に格納されたプログラムコードを読み出し実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体およびプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００９０】
また、本発明には、プログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた場合についても、本発明は適用される。その場合、書き込まれたプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される。
【図面の簡単な説明】
【００９１】
【図１】旧式の技術で動作している一般的な業務システムのブロック図である。
【図２】新技術で集約した業務システム群のブロック図である。
【図３】注文書システムのＸＭＬスキーマの図である。
【図４】注文書システムのＸＭＬスキーマの階層構造模式図である。
【図５】ＦＭＥｄｉｔｏｒのモジュール構成図である。
【図６】単純型データ要素の分解図である。
【図７】複合型データ要素の分解図である。
【図８】親子フィールド間のポインタによるリンクを示す図である。
【図９】フィールド自動配置処理フローチャート図である。
【図１０】フィールド幅計算概要図である。
【図１１】フィールド開始位置計算概要図である。
【図１２】フィールド高計算概要図である。
【図１３】自動配置結果を示す図である。
【図１４】繰り返しありの場合のフィールド自動配置処理フローチャートである。
【図１５】繰り返しありの場合の自動配置結果を示す図である。
【図１６】注文書システムのＸＭＬスキーマに適合したＸＭＬデータを示す図である。
【図１７】注文書システムのＸＭＬデータを流し込んだ自動配置表の図である。
【図１８】右クリック時に表示されるメニューの図である。
【図１９】親フィールド名称表示切り替え時のレイアウト図である。
【図２０】親フィールド名称非表示時の複合型フィールドレイアウト計算概要図である。
【図２１】親フィールド名称非表示時のフローチャートである。
【図２２】子フィールド名称表示切り替え時のレイアウト図である。
【図２３】子フィールド名称非表示時のフローチャートである。
【図２４】横並び表示切り替え時のレイアウト図である。
【図２５】横並び表示時の複合型フィールドレイアウト計算概要図である。
【図２６】横並び表示時のフローチャートである。
【図２７】まとめ表示設定フォームのオーバーレイ時の表示例の図である。
【図２８】集計行追加時のレイアウト図である。
【符号の説明】
【００９２】
１００  データベース
１０１  業務システム
１０２  クライアント端末
１０３  フォーム格納装置
１０４  帳票システム
１０５  プリンタ
２００  データベース
２０１  業務システム群
２０２  クライアント端末群
２０３  フォーム格納装置
２０４  帳票システム
２０５  プリンタ
１４０１  繰り返しありの場合に有効になるロジック
【図１】
2008052603.tif 000003
【図２】
2008052603.tif 000004
【図３】
2008052603.tif 000005
【図４】
2008052603.tif 000006
【図５】
2008052603.tif 000007
【図６】
2008052603.tif 000008
【図７】
2008052603.tif 000009
【図８】
2008052603.tif 000010
【図９】
2008052603.tif 000011
【図１０】
2008052603.tif 000012
【図１１】
2008052603.tif 000013
【図１２】
2008052603.tif 000014
【図１３】
2008052603.tif 000015
【図１４】
2008052603.tif 000016
【図１５】
2008052603.tif 000017
【図１６】
2008052603.tif 000018
【図１７】
2008052603.tif 000019
【図１８】
2008052603.tif 000020
【図１９】
2008052603.tif 000021
【図２０】
2008052603.tif 000022
【図２１】
2008052603.tif 000023
【図２２】
2008052603.tif 000024
【図２３】
2008052603.tif 000025
【図２４】
2008052603.tif 000026
【図２５】
2008052603.tif 000027
【図２６】
2008052603.tif 000028
【図２７】
2008052603.tif 000029
【図２８】
2008052603.tif 000030