ネストされたテーブル内にフロー可能なものを含む、かなり複雑な複数ページのレポートがあります。レポートは現在、当初の計画よりもはるかに長い内容で使用されています。レポートは 3 つのネストされたテーブルで問題なくリフローしますが、4 つ目のテーブルを追加すると、リフローしなくなり、次の応答でスクリプトがクラッシュします。
Flowable <Table@0x7FC7D4566200 1 rows x 3 cols(tallest row 1367)> with cell(0,1) containing '<Table@0x7FC7D4563638 3 rows x 4 cols(tallest row 1257)> with cell(0,1) containing\n\'<Table@0x7FC7D4556488 1 rows x 2 cols(tallest row 88)> with cell(0,0) containing\\n"<Table@0x7FC7D4561FC8 4 rows x 2 cols(tallest row 32)> with cell(0,0) containing\\\\n\\\'<Paragraph at 0x7fc7d45603f8>Classification\\\'"\''(612.0 x 1367), tallest cell 1367.0 points, too large on page 5 in frame 'normal'(600.0 x 664.0*) of template 'normal'
私の現在の回避策は、次の手順を実行することです。
- コンテンツを配置する前にページの位置を決定する
- コンテンツの長さを取得する
- 予想される残りの部屋を計算する
- コンテンツに必要なスペースを計算する
- コンテンツが収まる場合はページに追加し、そうでない場合:
- コンテンツをチャンク A とチャンク B の 2 つのチャンクに分割します (ただし、これにより xml の問題が発生する可能性があります)。
- チャンクAをページに追加
- テーブルを閉じる
- 新しいテーブルを開始
- 上記のステップ 1 からのチャンク B を処理します。
明らかに、このプロセスは問題をはらんでいます。誰かがより良い解決策を持っていますか?