2026年にHTMLをPDFに変換するためのC#ライブラリを選ぶ際、最も重要な決定は、実際に作成するドキュメントに最適なレンダリングエンジンを選ぶことです。 .NET 10では、この分野は3つのグループに分かれます。 ブラウザベースのエンジン（PuppeteerSharpやPlaywright、組み込みビルド経由のChromium）は、最新のCSSとJavaScriptを正確にレンダリングします。 プログラマティックなライブラリ（iText、PdfSharp）は、カスタムパーサーからPDFを描画し、モダンウェブの忠実度を小さなフットプリントに交換します。 コードファーストのレイアウトツール（QuestPDF）は、HTMLを完全にスキップします。 この比較では、動作するC#コード、評価基準、独自ベンチマーク、および出荷内容を決定するライセンス条項を伴う全てのオプションを探ります。
最新のCSSとJavaScriptを正確にレンダリングするには、ブラウザグレードのエンジンを使用してください。無料のルートではPuppeteerSharpやPlaywrightがあり、Chromeグレードの出力を提供しますが、独立したブラウザプロセスと大きなバイナリを管理する必要があります。 商業ルートでは、Chromiumをパッケージに組み込み、独立してインストールや起動するものはありません。 簡単な静的ドキュメントの場合、軽量のライブラリ（例: PdfSharp）で十分です。 HTMLソースがなく、コード定義のレイアウトの場合、QuestPDFが最短ルートです。
埋め込みエンジンを使用してPDFを作成する最速の方法は、単一のレンダー呼び出しです。
using IronPdf;
// The embedded Chromium engine ships inside the package, so no browser is launched or downloaded
var renderer = new ChromePdfRenderer();
// One synchronous call parses the HTML string and produces an in-memory PDF document
var pdf = renderer.RenderHtmlAsPdf("<h1>Invoice</h1><p>Generated from HTML.</p>");
// Write the rendered document to disk
pdf.SaveAs("output.pdf");完全な比較、ベンチマーク、およびライセンスの詳細は以下に続きます。
詳細を読む前に制約に合ったものを選んでください。
| 必要であれば | 推奨する選択 | なぜ | |---|---|---| | 最新のCSS、フレックスボックス、グリッド、大規模なウェブフォント | IronPDF（埋め込みChromium） | 正確なレンダリング、迅速なウォームレンダリング、外部ブラウザなしでのデプロイ | | 無料のブラウザグレードのレンダリング、オペレーション管理をいとわない |PuppeteerSharpまたは脚本家| 本物のChromium、MITライセンス、重いデプロイメントフットプリント | | 簡単な静的HTML、JavaScriptなし | PdfSharpとHtmlRenderer | 軽量、無料、レガシーCSSに制限 | | プログラム化された固定レイアウト、HTMLソースなし | QuestPDF | 流暢なC# API、非常に速く、HTMLレンダラーではない | | インフラゼロ、ホストされた処理 | HTML-to-PDF API | アプリ内で維持するレンダリングエンジンなし | | 古いプロジェクトでのwkhtmltopdf | Chromiumエンジンに移行 | wkhtmltopdfはアーカイブされ、現在のCSSには対応できず、重大なSSRF脆弱性（CVE）を抱えています。|
ブラウザは画面用に流動的なコンテンツをレンダリングします; PDFは固定ページ、正確な寸法、厳密なページ区切りを要求します。 これら二つのモデル間のギャップがライブラリの成功または失敗の分かれ目です。 5つの基準がこれらを区別し、ベンダーに関係なくすべてのツールに適用されます。
レンダリングエンジンと最新のCSS: HTMLとCSSを解析するエンジンが主要な差別化要素です。 現在のテンプレートは、CSSフレックスボックスでの配置、CSSグリッドでの2次元レイアウト、@font-faceでのタイポグラフィ、SVGでのベクトルアセットに依存しています。 旧WebKitフォークやカスタムパーサーに基づいたエンジンは、これらを静かに失敗させ、スタイルされたレイアウトを垂直スタックに崩します。 画面レイアウトを紙に変換する際には、@media printルールの正しい取り扱いが同じくらい重要です。
JavaScriptの実行とレンダリング待ち: 今日のコンテンツの多くはクライアントサイドで構築されています。Chart.jsなどのチャートライブラリやBlazor WebAssemblyなどのシングルページフレームワークは、ページが完成する前にJavaScriptでDOMを構築します。 JavaScriptエンジンのないライブラリは、白紙のチャートや読み込み途中のページを生成するため、スクリプトを実行してレンダリング準備完了の信号を待つ能力が動的ドキュメントにとって決定的です。
**デプロイメントの重量とコールドスタート:**外部のヘッドレスブラウザを駆動するツールは、数百MBのバイナリをダウンロードし、コンテナイメージを膨らませ、コールドスタートを遅くします。 AWS LambdaやAzure Functionsなどのサーバーレス環境では、保存容量とメモリが限られているため、コンテナの重量がライブラリの選択可否を決定することがあります。
**ライセンスとその法的範囲:**ライセンスはコスト以上のものを決めます。 .NET PDFの分野は、寛容な条項（MIT、Apache 2.0）、ネットワーク対応アプリのソース公開を要求することがあるコアプレフトの条項（AGPLv3）、収益制限付きのコミュニティティア、そして商用ライセンの条項にまたがります。 誤った選択が、監査時にのみ表面化する義務を作り出すことがあります。
**パフォーマンスとスケーラビリティでのメモリ:**コンソールテストでは問題なく動作するライブラリが同時実行のWeb APIの下で停止することがあります。 一些は作業をストリーミングします; 他の者はドキュメント全体を一度にメモリに読み込み、バッチジョブ中にガーベジコレクションの一時停止を引き起こします。 コールドスタート、ウォームレンダリング、レンダリングごとのメモリは、注意が必要な3つの測定です。
最初に無料のオープンソースオプションが登場します。以下のすべてのスニペットは.NET 10でコンパイルされ、実行され、ChromiumエンジンはHTML文字列およびURL入力の両方をサポートしています。
PuppeteerSharpは、Google for Node.js Puppeteer for .NETポートで、2017年に初めてリリースされました。それはChrome DevTools Protocolを介してヘッドレスChromiumのインスタンスを駆動します。 これはインプロセスライブラリというよりもプロセスオーケストレーターで、アプリケーションはBrowserFetcherを使用してChromiumビルドをダウンロードし、ブラウザを起動し、ページコンテンツを設定してPDFをキャプチャします。
using PuppeteerSharp;
using System.Threading.Tasks;
public class PuppeteerExample
{
public async Task GeneratePdfAsync()
{
// Download a matching Chromium build if it is not already present (the 100-300 MB fetch)
await new BrowserFetcher().DownloadAsync();
// Start a headless browser process; await using disposes it to avoid orphaned processes
await using var browser = await Puppeteer.LaunchAsync(new LaunchOptions { Headless = true });
// Open a fresh tab to work in
await using var page = await browser.NewPageAsync();
// Load the HTML directly into the page instead of navigating to a URL
await page.SetContentAsync("<h1>Invoice Report</h1><p>Rendered with PuppeteerSharp.</p>");
// Drive Chrome's print pipeline to emit the PDF file
await page.PdfAsync("puppeteer_output.pdf");
}
}文字列の代わりにライブURLをキャプチャする場合は、コール前にナビゲートしてください:
// Navigate the tab to a live URL so the loaded page becomes the render source
await page.GoToAsync("https://example.com");
// Capture whatever is currently displayed as a PDF
await page.PdfAsync("from_url.pdf");強み:
制限：
ライセンス: MIT。 無料のChrome-fidelity出力を望み、チームがオペレーションのオーバーヘッドを吸収できる場合に選んでください。 このトレードオフに焦点を当てた直接対決は、PuppeteerSharp対IronPDFの比較を参照してください。
###脚本家for .NET
Playwrightは、Microsoftによって維持されており、Chromium、WebKit、Firefoxのためのクロスブラウザの自動化フレームワークです。 チームはPage.PdfAsync経由でHTMLをPDFに再利用しますが、PDF生成はChromiumでのみ動作します。 セットアップでは、1回のインストールステップでブラウザバイナリを取得します。
using Microsoft.Playwright;
using System.Threading.Tasks;
public class PlaywrightExample
{
public async Task GeneratePdfAsync()
{
// Create the脚本家driver that manages the installed browser binaries
using var playwright = await Playwright.CreateAsync();
// PDF output is Chromium-only, so launch the Chromium build specifically
await using var browser = await playwright.Chromium.LaunchAsync();
// Open a new page (tab) to render into
var page = await browser.NewPageAsync();
// Set the HTML content in place rather than navigating to a URL
await page.SetContentAsync("<html><body><h1>Sales Dashboard</h1></body></html>");
// Emit the PDF with an explicit A4 page format
await page.PdfAsync(new PagePdfOptions { Path = "playwright_output.pdf", Format = "A4" });
}
}最初の実行前に、pwsh bin/Debug/net10.0/playwright.ps1 install chromiumを使用してブラウザをインストールします（またはコード内で同等のインストールエントリーポイントを呼び出してください）。
ライブURLの場合、最初にページへナビゲートしてください:
// Load a live URL so its rendered DOM becomes the PDF source
await page.GotoAsync("https://example.com");
// Export the loaded page as an A4 PDF
await page.PdfAsync(new PagePdfOptions { Path = "from_url.pdf", Format = "A4" });光り輝く点:
要注意点:
ライセンス: MIT。 プロジェクトで既にPlaywrightをテストに使っており、共に無料のレンダリングを望む場合に理想的です。
wkhtmltopdfは10年以上にわたり、HTMLからPDFへのデフォルトのツールでした。 .NETでは通常、DinkToPdfを通じて使用され、C#ラッパーがlibwkhtmltoxネイティブライブラリを覆っています。 ラッパーAPIはクリーンですが、その下のエンジンに問題があります。
using DinkToPdf;
public class DinkToPdfExample
{
public void GeneratePdf()
{
// SynchronizedConverter serializes calls into the non-thread-safe native libwkhtmltox library
var converter = new SynchronizedConverter(new PdfTools());
// Describe the document: global page settings plus one or more HTML content objects
var doc = new HtmlToPdfDocument
{
// Set the paper size and the output file path for the whole document
GlobalSettings = { PaperSize = PaperKind.A4, Out = "legacy_output.pdf" },
// Each object is a chunk of HTML to render into the PDF
Objects = { new ObjectSettings { HtmlContent = "<h1>Legacy Report</h1>" } }
};
// Hand the descriptor to the native engine, which writes the file defined in Out
converter.Convert(doc);
}
}このコードはコンパイルされますが、System.DllNotFoundException: Unable to load DLL 'libwkhtmltox'が原因で、クリーンマシンで実行するとネイティブバイナリが出力ディレクトリにコピーされるまでエラーが出ます。 そのネイティブ依存ステップが、このエンジンがもたらすデプロイメントの摩擦の最初の兆候です。
上昇点:
下降点:
ライセンス: DinkToPdfそのものはMITですが、LGPLv3 wkhtmltopdfバイナリとリンクされているため、実質的な義務はwkhtmltopdfから来ています。 セキュリティリスクを視野に入れたレガシーワークフローの移行待ちに適しています。 wkhtmltopdf対IronPDF比較を見て、フル移行の画像をご覧ください。
PdfSharpは広く利用されているオープンソースのライブラリですが、それが独自にHTMLを変換するという一般的な誤解があります。 それはそうではありません。 PdfSharpは低レベルの、座標ベースの描画APIを提供しています。 HTMLを変換するには、コミュニティの橋渡しHtmlRenderer.PdfSharpとペアにして、HTMLを解析しPdfSharpの描画コマンドを生成します。
using PdfSharp;
using TheArtOfDev.HtmlRenderer.PdfSharp;
public class PdfSharpExample
{
public void GeneratePdf()
{
string html = "<h1>Simple Title</h1><p>Statically rendered text.</p>";
// The HtmlRenderer bridge parses the HTML and emits PdfSharp drawing commands onto an A4 page
var pdf = PdfGenerator.GeneratePdf(html, PageSize.A4);
// Persist the resulting PdfSharp document to disk
pdf.Save("simple_document.pdf");
}
}.NET 10での2つのセットアップの詳細が重要です。ブリッジはWindows-1252コードページを期待しますが、これは最新 for .NETではデフォルトで存在しないため、Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)で起動時に一度登録します。 ブリッジを新しいPdfSharp 6.xパッケージとペアリングすると実行時にMissingMethodExceptionが発生するため、HtmlRendererが独自の互換性のあるPdfSharpを引っ張るようにし、最新バージョンにピン留めしないでください。
動作するもの:
壊れるもの:
page-break-inside: avoidのような印刷ルールはサポートされておらず、テーブル行はページをまたがります。ライセンス: PdfSharp MIT、HtmlRenderer BSD-3-Clause。 複雑なレイアウトのないシンプルな静的ドキュメントに最適な選択です。 PdfSharp対IronPDFの比較を見て、機能ごとの細分化をご覧ください。
QuestPDFは異なるアプローチを取ります: HTMLは捨て、流暢なAPIを通してC#でレイアウトを定義します。 マークアップではなくオブジェクトとして始まったデータに対しては、HTMLを生成してからそれを解析し直すステップを省きます。
using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;
public class QuestPdfExample
{
public void GeneratePdf()
{
// The revenue-gated license tier must be declared before any document is built
QuestPDF.Settings.License = LicenseType.Community;
// Compose the layout in C# through the fluent API; no HTML anywhere
var document = Document.Create(container =>
{
container.Page(page =>
{
// Define the physical page size and margins
page.Size(PageSizes.A4);
page.Margin(2, Unit.Centimetre);
// Place content into named page regions (header and body)
page.Header().Text("Programmatic Invoice").FontSize(24);
page.Content().Text("This document is generated without HTML.");
});
});
// Run the layout engine and write the composed document to a file
document.GeneratePdf("fluent_layout.pdf");
}
}強い点:
弱い点:
ライセンス: Community License（年間収益が100万USD以下の企業向けの無料）または有料のProfessionalとEnterprise層。 構造化データによって駆動されるコーディファインドで固定レイアウトのドキュメントに適しています。 QuestPDF対IronPDFの比較を見て、HTML対流暢なレイアウトのトレードオフをご覧ください。
iText 7および8はプログラム的なPDF操作で認識され、pdfHTMLアドオンはHTMLを変換します。 Chromiumツールとは異なり、pdfHTMLはHTMLタグをiTextオブジェクトにマップするカスタムパーサーを使用し、ブラウザを実行しません。
using iText.Html2pdf;
using System.IO;
public class iTextExample
{
public void GeneratePdf()
{
string html = "<h1>Report</h1><p>Converted with pdfHTML.</p>";
// Open the destination stream; using ensures the file handle is released after writing
using var dest = File.Create("output.pdf");
// pdfHTML maps the HTML tags to iText objects and writes them to the stream (no browser involved)
HtmlConverter.ConvertToPdf(html, dest);
}
}新しいプロジェクトでは、iTextがその暗号化パスのために必要とするitext7.bouncy-castle-adapterパッケージを追加するまでエラーが出ます。 その追加の依存関係は見落とされやすく、ないと不透明なエラーが発生します。
利点：
欠点:
ライセンス: AGPLv3または商用。 重度のPDF操作と規制追求ワークフローに、制御された静的HTMLで選ぶ。 iText 7対IronPDFの比較を参照してください。
IronPDFはNuGetパッケージ内にChromiumエンジンを埋め込み、C# APIを介してそれを公開するため、外部で起動またはプールする必要がありません。 無料のブラウザツールとプログラム的なライブラリの間に位置し、ブラウザを管理することなくレンダリングの忠実度のためにライセンス費用を交換します。
using IronPdf;
using System.Threading.Tasks;
public class IronPdfExample
{
public async Task GeneratePdfAsync()
{
// Create the in-process Chromium renderer (no external browser to launch)
var renderer = new ChromePdfRenderer();
// Turn on theJavaScriptengine so client-side chart scripts execute before capture
renderer.RenderingOptions.EnableJavaScript = true;
// Wait 500 ms after load to let JavaScript-built content settle before rendering
renderer.RenderingOptions.WaitFor.RenderDelay(500);
// Render the HTML string asynchronously into an in-memory PDF
var pdf = await renderer.RenderHtmlAsPdfAsync("<h1>Quarterly Report</h1><div class='chart'></div>");
// Save the finished PDF to disk
pdf.SaveAs("report.pdf");
}
}同じレンダラーが一度の呼び出しでURLをPDFに変換します:
// RenderUrlAsPdf fetches and renders the live page in one call, no navigation step needed
var fromUrl = new ChromePdfRenderer().RenderUrlAsPdf("https://example.com");
// Write the captured page to disk
fromUrl.SaveAs("from_url.pdf");また、RazorおよびMVCビューをPDFにレンダリングし、HTMLファイルを直接変換します。 完全な機能ウォークスルーはHTMLからPDFのチュートリアルにあります。
利点:
欠点:
ライセンス: 商用、永続。 大量の最新CSSが重要で、オペレーションオーバーヘッドを削減しつつ、高い忠実度を維持することが優先される場合に使用してください。
各ライブラリごとに1行、ライセンスコラムが含まれるので、無料と有料の決定を直接駆動します。
|ライブラリ| エンジン |JavaScript|モダンCSS| デプロイメント重量 |ライセンス| 最適な用途 | |---|---|---|---|---|---|---| |IronPDF|埋め込まれたChromium| はい | フル| 軽量 (NuGet) | 商用 | 大規模な最新のCSS | |PuppeteerSharp| 外部Chromium | はい | フル| 重い (バイナリダウンロード) | MIT | 無料のブラウザレンダリング | |脚本家| 外部Chromium | はい | フル| 重い (バイナリダウンロード) | MIT | 最新の無料レンダリング | | wkhtmltopdf | 古いQtWebKit | 制限的 | 弱い | 中程度 （ネイティブライブラリ） | LGPLv3 (ラッパーMIT) | レガシーワークフロー | |PdfSharp + HtmlRenderer| カスタム描画 | なし | 制限的 | 軽量 |MIT / BSD-3| シンプルな静的HTML | | QuestPDF | プログラム的 | 該当なし | 該当なし | 軽量 | コミュニティ / 有料 | コード定義のレイアウト | |iText pdfHTML|カスタムパーサー| なし | 制限的 |中規模| AGPLv3 / 商用 |PDF操作|
各ライブラリの最新リリースに対して各セルを検証してください。ライセンスおよびエンジンのサポートは変更される可能性があります。
"無料"のツールは.NET PDF分野で運用および法的コストを隠すことがあるので、無料ツールが正しい選択となるケースを挙げることが正しいスタートポイントです。
無料のオープンソースライブラリは、単純な静的ドキュメント、小ボリューム、または外部プロセスを管理するオペレーション能力を持つチームにとっては十分です。 複雑なスタイリングのないテキスト重視のレシートは、MITライセンスのPdfSharpで問題なくレンダリングされます。チームがすでにPlaywrightをテスト用に実行し、コンテナ化を解決している場合、時々のPDFジョブに再利用することは効率的です。
フリーソフトウェアはフリーの実装を意味するものではありません。 オープンソースヘッドレスブラウザの隠れたコストは、ブラウザのライフサイクルをプールしてサーバーが負荷でクラッシュしないようにし、コンテナイメージ間でLinuxの共有ライブラリ依存を設定するメンテナンス時間や、ヘビーなブラウザプロセスのインフラコストを吸収することで明らかになります。 些細な静的ドキュメントにとって、有料のブラウザエンジンは過剰であり、軽量で無料のライブラリがより良い選択です。
商業的なChromiumライブラリは、正確なCSS3のレンダリング、アクセス可能なPDF/UAの出力、および調達コストよりも展開の簡便性が要求される時に妥当になります。商業ライセンスはまたコープレフトの露出を除去します。 iTextのようなAGPLv3ライブラリをSaaSプラットフォームに追加すると、商用ライセンスが購入されない限り、会社にソースコードを公開する義務を課すことがあります。 実際の比較は総所有コストです：運用時間と法的リスクが一方に、ライセンス料金が他方に。
以下のすべての数値は1つのマシンでの実際の実行からのものなので、目安として扱ってください。 テストドキュメントは、ヘッダーにCSSグリッドを使用し、インラインJavaScript棒グラフを持つ30行の請求書です。 テストは標準のWindowsワークステーション上で.NET 10で行われました。各ウォームフィギュアは最初のものを除いた8回のレンダリングの平均であり、ピークメモリは.NETプロセスの作業セットにスポーンされたブラウザ子プロセスを加えたもののピーク値です。
|ライブラリ| コールドスタート（1プロセスあたり） | ウォームレンダリング（8回の平均） | ピークメモリー | |---|---|---|---| |IronPDF|345 ms|202 ms|406 MB| |PuppeteerSharp|746 ms|204 ms|611 MB| |脚本家|588 ms|132 ms|515 MB| | wkhtmltopdf、iText、PdfSharp | sub-second | not comparable | 50〜120 MB |
ウォーム時、3つのブラウザエンジンは同じドキュメントをおおよそ130〜200 msでレンダリングし、この実行ではPlaywrightが最速で、IronPDFおよびPuppeteerSharpがそれに続きます。 コールドスタートでは、埋め込みエンジンが最速で起動し、起動に独立したブラウザが不要だからです。ただし、ブランドニューデプロイ後の最初のレンダーでは、エンジン初期化コストが一度だけ吸収され、その後のプロセス起動ではスキップされます。レガシーおよびカスタムパーサーのツール（wkhtmltopdf、iText、PdfSharp）は1秒未満で起動し、最も少ないメモリを使用しますが、このテストドキュメントに対するその優位性は無有です。なぜなら、これらはそのグリッドレイアウトやJavaScriptチャートを正しくレンダリングすることができないからです。 wkhtmltopdfは、最初にネイティブバイナリを供給しない限り、全く実行できませんでした。
忠実度のギャップは出力で示されます。 ブラウザエンジンはCSSグリッドヘッダー、スタイル適用テーブル、およびJavaScript棒グラフをレンダリングします：
PdfSharpとHtmlRendererを通じて同じドキュメントを参照すると、グリッドヘッダー、テーブルヘッダースタイリング、およびJavaScriptチャートが欠けています：
各一般シナリオに対する簡単な判断:
重いCSSフレームワーク出力が、低いオペレーションニーズを満たす場合、IronPDFは最初に手を伸ばすための埋め込みオプションです。一方で、無料のブラウザツールは、ヘッドレスブラウザに関するオペレーションを所有できるチームにとって正しい選択です。
最も大きな摩擦は、Windowsラップトップ上で動作するライブラリとLinuxコンテナで失敗するライブラリとのギャップです。 ライブラリを選ぶことは、どこに出荷されるかを予期することを意味します。
Dockerでは、PuppeteerSharpやPlaywrightのような編成されたブラウザには、libgbm1などChromiumのLinux依存関係を持つベースイメージが必要です。 Microsoftはv1.NN.0-nobleタグ）のPlaywright .NETイメージを公開してこれをカバーしており、これらのイメージは約1ギガバイトに達します。 埋め込みエンジンは、apt-getステップなしで動作させます。
AWS Lambdaは異なる壁を設けます。 展開されたデプロイメントパッケージには250 MBのハードリミットがあり、ヘッドレスChromiumビルド単独で150 MBから300 MBです。 そのため、PuppeteerSharpやPlaywrightを標準zipで展開することは現実的ではなく、コンテナベースのLambdaにチームを押しやることになり、最大10 GBを許可しますが、コールドスタートが悪化します。
Azure App Serviceは、オペレーティングシステム上の制約を追加します。 Windows App Serviceのサンドボックスは、ほとんどのUser32とGDI32呼び出しをブロックし、GDI依存のレンダリングパスを破ります。 Linux App ServiceにDinkToPdfを展開すると、libxrender1などの依存をインストールする必要があります; 欠けているものは、不透明なSystem.DllNotFoundExceptionとして表面化します。 これらは、検証実行が再現したのと同じネイティブ依存性とサンドボックスの問題です。
.NET 10のC# HTMLからPDFへの変換は、ツールをドキュメントに合わせることで報われます。 完全なブラウザエンジンは、CSSフレームワークおよびレスポンシブレイアウトおよびJavaScript駆動のページのベースラインであり、無料と商業の間の分割は運用努力とライセンスコストの分割です。プログラム可能なライブラリは、固定された静的なレイアウトに対して効率的であり、入力がマークアップではなく構造化データである場合、QuestPDFは最短ルートです。wkhtmltopdfはアーカイブされたエンジンと未修正のSSRFの欠陥があるため、移行プランにのみ属します。 より少ないオペレーションオーバーヘッドで正確なレンダリングを望むチームにとって、IronPDFはデフォルトの埋め込みオプションであり、URLをPDFに変換、Razorビューのレンダリング、PDF/Aの出力、およびデジタル署名が同じAPIから利用できます。一方で、PuppeteerSharpやPlaywrightは、ブラウザのライフサイクルをチームが所有できる場合には強力な無料の選択肢です。
軽量の出荷コストで正確なレンダリングがプロジェクトに合う場合、無料のIronPDF体験版を開始し、コミットする前にこの同じテスト請求書を自分のテンプレートに対して実行できます。 IronPDFは、.NETライブラリでもあるIron Softwareによって構築されています。
読んでくださりありがとうございます。 どのライブラリを選んでも、目の前のドキュメントに合わせてください。
Curtis Chau holds a Bachelor’s degree in Computer Science (Carleton University) and specializes in front-end development with expertise in Node.js, TypeScript, JavaScript, and React. Passionate about crafting intuitive and aesthetically pleasing user interfaces, Curtis enjoys working with modern frameworks and creating well-structured, visually appealing manuals.
オフィス文書向けの.NET API製品10個
PDFがHTMLのように見える必要があるとき、迅速に。
