帳票エンジンの深淵：FlowDocumentとPaginatorによる動的レイアウトの極致
業務システムの現場において、「帳票」は単なるデータの出力結果ではない。それは、企業の意思決定を支える公式な記録であり、レガシーな会計システムから最新のクラウドAPIまでを繋ぐ、情報の最終到達点である。
多くの開発者は、WPFの `PrintDialog.PrintVisual` を使い、目の前の `UIElement` をそのままプリンターに放り込むことで「印刷機能」を実装しようとする。しかし、それは極めて素人臭いアプローチだ。動的なページ増減、複雑な表組み、そして何より「画面上の見た目」と「物理的な紙面」の微細な差異を制御できない。
本稿では、プロフェッショナルとして、`FlowDocument` と `DocumentPaginator` を駆使し、メモリ効率とレイアウト精度を極限まで高めた、真に堅牢な帳票出力アーキテクチャを解説する。
1. 概念の再定義：Fixed か Flow か
WPFにおけるドキュメント表現には、大きく分けて二つの流派がある。
1. FixedDocument: PDFのように、座標（X, Y）を完全に固定する。ページごとに「何がどこにあるか」を厳密に定義するが、コンテンツの増減に伴う改ページ処理はすべて開発者が手動で行わなければならない。
2. FlowDocument: テキストや要素が「流れる」ように配置される。コンテンツ量に応じて自動的に改ページが行われる。
業務帳票、特に「明細行数によってページが変わる請求書」や「長大な報告書」において、我々が選択すべきは後者、FlowDocument である。しかし、FlowDocumentを単に `FlowDocumentReader` に表示するだけでは、印刷における「解像度の乖離」と「メモリリーク」の罠に嵌まることになる。
2. アーキテクチャ設計：データと表現の完全分離
伝説的な設計とは、常に「データの生成」と「ビジュアルの構築」を分離している。UIスレッドで直接、巨大なドキュメントオブジェクトを構築してはならない。それはユーザーインターフェースの凍結（Freeze）を招き、最悪の場合、大規模なメモリ消費によってプロセスがクラッシュする。
我々は、以下の三層構造を採用する。
- Data Layer: 純粋なDTO（Data Transfer Object）。
- Logic Layer: `FlowDocument` の構造を定義する（非同期実行を推奨）。
- Presentation Layer: `PrintDialog` を介した物理デバイスへの出力。
3. 実装の極致：動的帳票生成エンジン
以下に、メモリ管理とレイアウト精度を考慮した、実戦的な実装パターンを示す。
“`vb.net
Imports System.Windows
Imports System.Windows.Documents
Imports System.Windows.Media
Imports System.Windows.Controls
Imports System.Threading.Tasks
”’
”’ 責務を明確に分離し、メモリリークを最小限に抑える設計。
”’
Public Class ReportEngine
Implements IDisposable
‘ 印刷設定の定数
Private Const DefaultMargin As Double = 36.0 ‘ 0.5 inch
”’
”’
”’ 帳票データ
”’
Public Async Function GenerateInvoiceDocumentAsync(data As InvoiceData) As Task(Of FlowDocument)
‘ 重い計算やデータ整形はTask.Runでバックグラウンドへ逃がす
Return Awake Task.Run(Function()
Dim doc As New FlowDocument()
doc.PagePadding = New Thickness(DefaultMargin)
doc.PageWidth = 792 ‘ Letter size width (96 DPI)
doc.PageHeight = 612 ‘ Letter size height (96 DPI)
‘ セクションの構築
Dim section As New BlockCollection()
‘ タイトル（Heading）
Dim title As New Paragraph(New Run(“請求書”))
title.FontSize = 24
title.TextAlignment = TextAlignment.Center
doc.Blocks.Add(title)
‘ 明細テーブルの構築
Dim table As New Table()
table.Columns.Add(New TableColumn() With {.Width = New GridLength(1, GridUnitType.Star)})
table.Columns.Add(New TableColumn() With {.Width = New GridLength(100, GridUnitType.Pixel)})
‘ ヘッダー行
Dim headerRow As New TableRow()
headerRow.Cells.Add(New TableCell(New Paragraph(New Run(“品名”))))
headerRow.Cells.Add(New TableCell(New Paragraph(New Run(“金額”))))
table.Rows.Add(headerRow)
‘ データ行のループ
For Each item In data.Items
Dim row As New TableRow()
row.Cells.Add(New TableCell(New Paragraph(New Run(item.Name))))
row.Cells.Add(New TableCell(New Paragraph(New Run(item.Amount.ToString(“C”)))))
table.Rows.Add(row)
Next
doc.Blocks.Add(table)
Return doc
End Function)
End Function
”’
”’ PrintDialogのライフサイクルを制御し、リソースを確実に解放する。
”’
Public Sub PrintDocument(doc As FlowDocument, printerName As String)
Dim printDialog As New PrintDialog()
‘ プリンター設定の適用
printDialog.PrintQueue = PrintDialog.PrintQueues.FirstOrDefault(Function(q) q.Name = printerName)
If printDialog IsNot Nothing AndAlso printDialog.PrintableAreaWidth > 0 Then
‘ FlowDocumentをPaginatorとして扱う。これが印刷精度の鍵。
‘ Paginatorを介することで、物理的な用紙サイズに基づいた正確な改ページが行われる。
Dim paginator As DocumentPaginator = doc.DocumentPaginator
‘ 印刷実行
printDialog.PrintDocument(paginator, doc.Name)
End If
End Sub
Public Sub Dispose() Implements IDisposable.Dispose
‘ 巨大なドキュメントを保持している場合は、明示的に参照を切り、GCを促す
‘ ただし、WPFのDependencyObjectはGCの挙動が特殊であるため、
‘ 呼び出し元でのライフサイクル管理が重要となる。
End Sub
End Class
”’
”’
Public Class InvoiceData
Public Property Items As List(Of InvoiceItem)
End Class
Public Class InvoiceItem
Public Property Name As String
Public Property Amount As Decimal
End Class
“`
4. アーキテクトの視点：メモリとパフォーマンスの最適化
ここからは、一般的な開発者が陥る「罠」を回避するための、極限の知見を共有する。
4.1 DependencyObject の重み
`FlowDocument` やその構成要素（`Paragraph`, `Run`, `Table`）はすべて `DependencyObject` を継承している。これらは通常の .NET オブジェクトよりも遥かにメモリ消費量が多い。
大量の帳票をループ内で連続生成する場合、`FlowDocument` インスタンスを使い回してはいけない。生成、印刷、そして参照の破棄を徹底すること。特に、`FlowDocumentReader` などのコントロールにセットしたままにすると、コントロールがドキュメントを掴み続け、GC（Garbage Collector）が回収できなくなる。
4.2 Windows API とプリンター・スプーラー
WPFの `PrintDialog` は内部的に Win32 API を呼び出している。大規模なシステムにおいて、印刷コマンドを大量に送ると、プリンター・スプーラー（Print Spooler）がボトルネックとなり、アプリケーション全体の応答性が低下することがある。
もし、バッチ処理として数千枚の印刷を行う必要があるなら、WPFの UI レイヤーを介さず、`PrintServer` クラスを使用して直接スプーラーにジョブを投入するか、あるいは PDF への書き出しに切り替えるべきだ。
4.3 解像度の整合性 (DPI Awareness)
画面上の `FlowDocument` は通常 96 DPI でレンダリングされる。しかし、物理プリンターは 600 DPI や 1200 DPI という高解像度で動作する。
`PrintDocument(paginator, …)` を使用する場合、`DocumentPaginator` はプリンターの解像度に合わせて適切にスケーリングを行う。しかし、画像（`Image` 要素）を帳票に組み込む場合は注意が必要だ。低解像度のビットマップをそのまま流し込むと、印刷時に「ぼやけた」結果となる。必ず、印刷解像度を意識した高精細なソースを使用せよ。
5. 結論
WPFにおける帳票実装は、単なる「見た目の構築」ではない。それは、「動的なデータの構造化」と「物理的なデバイス制約の制御」の高度な融合である。
`FlowDocument` を使いこなし、`DocumentPaginator` の特性を理解し、メモリのライフサイクルを制御できるエンジニアこそが、真に信頼される業務システムの設計者（アーキテクト）と呼ばれるにふさわしい。
技術の深淵は、常に、細部への執着の先に広がっている。
