🥁 👆🏼 💂 WPFアプリケーションからPDFを生成し、「すべての人のために、何のためにも、誰も気分を害さないように」 😋 🧖🏻 👉

数週間前、PDF生成タスクがプロジェクトに登場しました。

もちろん、私はWPF UIの開発者として、すべてのPDFプリミティブのレンダリングをC＃コードでコーディングするという厳しいアプローチにすぐに反対しました。

また、顧客は、たとえばHTMLからPDFへの特定の有料コンバーターの購入に反対しませんでした。

すべてがシンプルに思えます-テンプレート生成にDotLiquidを使用してHTMLマークアップを含む行を生成し、多くの有料コンバーターのいずれかを使用してPDFに変換します。

唯一の待ち伏せは、PDFドキュメントのページ構造とのHTML互換性の低さです。

この問題の解決策を探し始めてすぐに、ある同僚が別の解決策がある記事へのリンクを共有しました。

この記事から、XPSドキュメントからPDFを生成できることを学びました（この形式はWPF FlowDocumentでサポートされています）。

さらに、無料のPDFSharpライブラリーが生成に使用されました。

ソースはGitHubからダウンロードできます。

UPD ：カルマをマージしながら、記事がどのように追加されるかを観察したのはこれが初めてではありません（最初の欠点は発行直後であり、メインコンテンツに関連する可能性は低い）。 動機付け、フィードバックに興味があります。 困難ではないにしても、誰が何に不満を持っているかを退会してください。

免責事項

注意を喚起するソースコードは、従うべき例ではありません。記事を引きずらないようにするため、デザインパターンには従いませんでした。ソースコードは、単純な「コードビハインド」アプローチです。これは、本質の認識を容易にするためにも行われます。 PDF生成自体に焦点を合わせます。主なコードをプロジェクトの構造に簡単に統合できると思います。

また、ソースでは、DotLiquidテンプレートのデータソースとしてのdynamicの大規模な使用に遭遇します。これも主に単純さと速度のために行われました。 DotLiquid Webサイトには、テンプレートで使用できるように独自のクラスに注釈を付ける方法の説明があります。ここで、私のソースをニーズに簡単に適合させることもできます。

まあ、PDFSharpがFlowDocument / XPS擬似フォントの問題を検出したことにも言及する価値があります。特に、レンダリングされたXPSのレンダリングされていないリストマーカーは、空の四角形としてPDFにエクスポートされます。デバッグモードで、フォントのインポート/エクスポートエラーが発生したDebug.Assert（...）メッセージを受け取りました。この問題はまだ調査されていません。リストの問題はテンプレートで簡単に回避できます。

準備する

以下は、必要な操作のリストです。

変更されたPDFSharpに関するサイトにアクセスし、そこからコンパイルされたアセンブリまたはソースコード自体をダウンロードします。別の方法は、PDFSharpバージョン1.2〜1.31です。
NuGetを使用してDotLiquidライブラリ（執筆時点ではバージョン1.7.0）をインストールします（まだインストールしていない場合はNugetをインストールします）
System.PrintingおよびReachFrameworkアセンブリへの参照を、PDFが生成されるプロジェクトに追加します。

メインウィンドウ

以下はメインウィンドウのレイアウトです。

<Window x:Class="Solution.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Title="MainWindow" Height="480" Width="640"> <Grid> <Grid.RowDefinitions> <RowDefinition></RowDefinition> <RowDefinition Height="Auto"></RowDefinition> </Grid.RowDefinitions> <FlowDocumentReader x:Name="DocViewer"> <FlowDocument> <FlowDocument.Resources> <Style TargetType="TextBlock"> <Setter Property="FontSize" Value="14"/> <Setter Property="Margin" Value="5"/> </Style> </FlowDocument.Resources> <BlockUIContainer> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="Auto"/> <ColumnDefinition Width="Auto"/> <ColumnDefinition /> </Grid.ColumnDefinitions> <Ellipse Fill="#003481" Width="5" Height="5" Margin="5"/> <TextBlock Text="Title" FontWeight="Bold" Grid.Column="1"/> <TextBlock Text="Description" Grid.Column="2"/> </Grid> </BlockUIContainer> </FlowDocument> </FlowDocumentReader> <StackPanel Grid.Row="1" Orientation="Horizontal"> <Button Click="ParseButton_OnClick">Parse</Button> <Button Click="ButtonBase_OnClick">Print</Button> </StackPanel> </Grid> </Window>

ここには、レンダリングされたFlowDocumentを表示するFlowDocumentReaderがあります。マークアップでは、Visual Studioのデザイナーを使用してテンプレートを作成するために使用するハードコードされたFlowDocumentも確認できます。

また、通常のコントロールとWPFスタイルを使用していることもわかります。これは、FlowDocumentを使用してPDFを生成することの大きなボーナスの1つです。 WPFアプリケーションのコントロールとスタイルリソースを使用できます。 HTMLを仲介として使用するアプローチの場合、CSSスタイルとHTMLの一部のアセンブリを個別にサポートする必要がありますが、これらはまだ何らかの形でテンプレートに埋め込む必要があります。

テンプレートのデータコンテキスト

データコンテキストを生成するために、メインウィンドウのコードビハインドにプライベートメソッドを追加しました。このメソッドでは、動的オブジェクトのDotLiquid.Hashの作成がハードコーディングされています。

  private DotLiquid.Hash CreateDocumentContext() { var context = new { Title = "Hello, Habrahabr!", Subtitle = "Experimenting with dotLiquid, FlowDocument and PDFSharp", Steps = new List<dynamic>{ new { Title = "Document Context", Description = "Create data source for dotLiquid Template"}, new { Title = "Rendering", Description = "Load template string and render it into FlowDocument markup with Document Context given"}, new { Title = "Parse markup", Description = "Use XAML Parser to prepare FlowDocument instance"}, new { Title = "Save to XPS", Description = "Save prepared FlowDocument into XPS format"}, new { Title = "Convert XPS to PDF", Description = "Convert XPS to WPF using PDFSharp"}, } }; return DotLiquid.Hash.FromAnonymousObject(context); }

免責事項に書いたように、これはほんの一例です。実際のプロジェクトでは、実際のDTOまたはViewModel用の何らかのコンバーターが必要です。

DotLiquidページの開発者マニュアルには、テンプレートの文字列値を表示するために、任意のクラスのインスタンスを使用することはできないと書かれています。たとえば、テンプレートのDateTimeオブジェクトの出力を記述する場合、パラメーターなしのToString（）の出力は、レンダリングされたドキュメントに入ります。ただし、作成したオブジェクト、たとえばBlaBlaUserが有効になっている場合、DotLiquidは代わりにエラー文字列を表示します。そして、これは、ところで、非常に良いです、なぜならテンプレートは引き続きレンダリングされますが、間違えた特定の場所がすぐに表示されます。

模様

 <FlowDocument xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> <FlowDocument.Resources> <Style TargetType="TextBlock"> <Setter Property="FontSize" Value="14"/> <Setter Property="Margin" Value="5"/> <Setter Property="TextWrapping" Value="Wrap"/> </Style> </FlowDocument.Resources> <Paragraph FontSize="24"> <Bold>{{ Title }}</Bold> </Paragraph> <Paragraph FontSize="16"> {{ Subtitle }} </Paragraph> <Paragraph FontSize="16"> <Bold>Steps to generate PDF:</Bold> </Paragraph> {% for step in Steps -%} <BlockUIContainer> <Grid> <Grid.ColumnDefinitions> <ColumnDefinition Width="Auto"/> <ColumnDefinition Width="Auto"/> <ColumnDefinition /> </Grid.ColumnDefinitions> <Ellipse Fill="#003481" Width="5" Height="5" Margin="5"/> <TextBlock Text="{{ step.Title }}" Foreground="#003481" FontWeight="Bold" Grid.Column="1"/> <TextBlock Text="{{ step.Description }}" Grid.Column="2"/> </Grid> </BlockUIContainer> {% endfor -%} </FlowDocument>

TextBlock.Text属性でDotLiquidコンテキストに直接バインディングを挿入する代わりに、ネストされたCDATAブロックを使用する方が安全であることに注意してください。

 <TextBlock Foreground="#003481" FontWeight="Bold" Grid.Column="1"> <![CDATA[ {{ step.Title }} ]]> </TextBlock>

これにより、XML形式と互換性のない文字から保護されます。

FlowDocumentのレンダリングと解析

  private void ParseButton_OnClick(object sender, RoutedEventArgs e) { using (var stream = new FileStream("Templates\\report1.lqd", FileMode.Open)) { using (var reader = new StreamReader(stream)) { var templateString = reader.ReadToEnd(); var template = dotTemplate.Parse(templateString); var docContext = CreateDocumentContext(); var docString = template.Render(docContext); DocViewer.Document = (FlowDocument) XamlReader.Parse(docString); } } }

ここではすべてが簡単です。テンプレートでファイルストリームを開き、テンプレートコンテキストを作成してFlowDocumentマークアップをレンダリングします。 XamlReaderを使用して、結果のマークアップを解析し、作成したインスタンスをFlowDocumentReaderに配置します。すべてが私たちに合っている場合は、このドキュメントのPDFへの変換に進みます。

PDF生成

  private void ButtonBase_OnClick(object sender, RoutedEventArgs e) { using (var stream = new FileStream("doc.xps", FileMode.Create)) { using (var package = Package.Open(stream, FileMode.Create, FileAccess.ReadWrite)) { using (var xpsDoc = new XpsDocument(package, CompressionOption.Maximum)) { var rsm = new XpsSerializationManager(new XpsPackagingPolicy(xpsDoc), false); var paginator = ((IDocumentPaginatorSource)DocViewer.Document).DocumentPaginator; rsm.SaveAsXaml(paginator); rsm.Commit(); } } stream.Position = 0; var pdfXpsDoc = PdfSharp.Xps.XpsModel.XpsDocument.Open(stream); PdfSharp.Xps.XpsConverter.Convert(pdfXpsDoc, "doc.pdf", 0); } }

そして、ここではすべてが簡単です。 XPSドキュメントパッケージが生成されます（ご存じのとおり、XPSは多くのXMLおよびその他のリソースを含むzipアーカイブです）。以前にレンダリングされたFlowDocumentは、作成されたXPSパッケージに保存されます。（閉じる前に！）XPSパッケージのストリームは、PDFSharpを使用してXPSドキュメントをダウンロードしています。その後、ダウンロードされたXPSはPDFに変換されます。

おわりに

結論として、このアプローチで自分のために特定した利点のリストを提供したいと思います。

無料-無料のライブラリ（MIT）の助けを借りて、重要なビジネス上の問題の1つを解決することができました
仲介としてのFlowDocument-これは、ページ構造のほぼネイティブサポートであり、ドキュメント内でWPFコントロールを使用する機能です。
スタイリング-FlowDocumentの使用のおかげで、スタイルを使用してWPFドキュメントをスタイル設定できます
インタラクティブ性-なぜなら WPFコントロールを使用して、PDFの「印刷」の前に、必要に応じて、ドキュメント内でいくつかの変更と計算を行うことができます。この場合、Bindingの使用も可能です（これにはいくつかの問題がありますが、DispatcherがBindingの更新を開始するにはキックが必要です）。
ビジュアルデザイナー-テンプレートを準備するときに、通常のVisual Studioデザイナーを使用できます。唯一の不満は、フォーム "{{someProp}}"のDotLiquidバインダーがXAMLマークアップと互換性がないことです。「{}」の先頭で挿入をバイパスできます：<TextBlock Text = " {} {{step.Title}}" ... />

ご清聴ありがとうございました！

WPFアプリケーションからPDFを生成し、「すべての人のために、何のためにも、誰も気分を害さないように」