IronPDF的產品比較

產品的文件是使其在長期與開發者中存活或消亡的關鍵。 當他們深入並需要更多高級功能時，他們能多快找到該材料和是否提供範例來幫助教導這些概念。

在這些產品中的每一個中，我搜尋了他們的API文件，以查找在PDF中添加數位簽名的能力。

IronPDF

API文件清晰且井然有序，左邊面板有實時篩選的內容目錄。 右上角的搜尋框還包括一個實時篩選，並快速返回有關提供簽名功能的各種組件的幾篇文章。 API網站有一個淺色和深色模式，一個開發者喜愛的功能。

圖15 - IronPDF對簽名的API搜尋結果

PdfSignature類文件描述了物件但不包括任何到範例代碼的連結。 我搜尋了ironpdf.com網站上的"簽名"，並找到了一個參考到PdfSignature物件的範例代碼，位於IronPDF數位簽署PDF範例。

Aspose

Aspose的API文件在我搜尋簽名時鏈接我到他們的PdfFileSignature類。 這個頁面和IronPDF的類似，顯示PdfFileSignature類的詳細資訊，但不包括到範例的連結或描述如何使用該類。

我回到Aspose的文件基本頁面Aspose PDF for .NET 文檔並搜尋簽名。 然後我看到一篇相關文章的列表， 點擊進入"在PDF文件中添加簽名"文章Aspose在PDF中添加簽名。

SyncFusion

SyncFusion的基本文件頁面位於文件格式產品中的Syncfusion PDF文件格式概述，需要點擊幾次才能找到。 我不必走太遠就找到簽名範例，因為文件的首頁。

在SyncFusion網站上沒有支援數位簽名功能的API文件。

iText

iText的API文件非常全面，來自每個發佈版本生成的。 這是您能在互聯網上從其他程式庫看到的標準外觀和感覺。 搜尋簽名找到了包含對這些功能的詳細描述的一些類，但仍然沒有連結到範例。

我搜尋iText網站的簽名範例，卻找不到，只看到幾篇宣佈新合作夥伴關係的部落格文章。

這些工具提供的API非常詳細，每個都有自己獨特方法，讓開發者完全訪問創建和管理PDF文件的內容。 幸運的是，所有框架都有完整的自動完成提示，在您使用它們的工具時提供優秀的內嵌文件，像Visual Studio或Visual Studio Code這樣提供自動完成功能的現代代碼編輯器。

IronPDF

IronPDF API讓非常困難和複雜的互動變得簡單，使用像"RenderHtmlAsPdf"這樣的簡化指令，但仍然提供深入訪問該文件的創建和配置、安安全性、元數據和表格的訪問。 作為一個開發者，這些API"符合我對內容呈現的思維方式"。

IronPDF API使用的名稱和術語非常明確，您正在渲染一個文件或構建一個文件。 部分設置上的時間屬性是整數，表示毫秒，我希望有一個本機TimeSpan類型。 最後，我希望看到Settings和Options類型提供了現代流暢的配置API，比如這樣：

var renderer = new IronPdf.ChromePdfRenderer(options => {
    options.RenderDelay = TimeSpan.FromSeconds(1);
});

var renderer = new IronPdf.ChromePdfRenderer(options => {
    options.RenderDelay = TimeSpan.FromSeconds(1);
});

SyncFusion

SyncFusion API很清晰，提供了非常詳盡的控制，以便控制他們的轉換器工具。 在這裡沒有捷徑可走，所有選項都需要預先指定，您必須告訴它使用哪些工具，並無任何預設。 設置是全面且具有細小粒度的控制一切，包括磁碟上的WebKit渲染器的位置。

這種額外的配置，儘管在某些安裝中不需要，過去和未來的版本中都造成了一些問題，SyncFusion承諾不會成為問題。

Aspose

Aspose的API非常冗長，讓我想知道他們是否試圖讓開發者更加高效。 從網站加載一個文件所需的配置量令人驚訝，需要十行代碼或是SyncFusion（五行代碼）的兩倍多。

其中一個例子是，Aspose沒有API允許您指定要抓取和轉換的URL。

iText

iText有一個與Aspose相似的API，非常冗長，可以直接互動進入不同數據類型的文件，但不清楚如何創建文件的部分。 由於這些API的明確性和文件的低質量，使用iText是很困難的。

參考網站非常簡單，沒有CSS，只有帶鏈接和圖片的文本。

圖16 - 靜態Web測試的參考網站

IronPDF

這是一個簡單的三行代碼來執行，性能在835毫秒看起來不錯。 然而，當我打開PDF時，我發現渲染時沒有包含任何圖片，這是預設配置的一個令人失望的結果。

經過一點探查，我發現我可以添加渲染延遲，在這種配置下，我能夠渲染包含頁面上的正確圖片的PDF。

使用工具的測試版，滲透的水印會在渲染的PDF中被包含。 在完全授權版本中，這個水印不存在。

圖17 - IronPDF渲染的靜態站點

SyncFusion

SyncFusion是一趟好奇且困惑的旅程。他們的文件提到多種不同方法來渲染和交付HTML和PDF，使用不同的版本號和不同的框架，需要不同的代碼和配置以及二進位工具的安裝才能正常工作。

類似IronPDF範例，SyncFusion沒有渲染頁面的圖片，而是交付了邊距非常小的PDF。

使用工具的測試版，滲透的水印會在渲染的PDF中被包含。 在完全授權版本中，這個水印不存在。

圖18 - SyncFusion渲染的靜態站點

Aspose

Aspose有一套非常清晰的指示說明如何使用它們的工具。 然而，根據其網站上關於將網站轉換為PDF的說明，他們有一個重大錯誤，導致該功能無法發揮作用。 此外，其在線工具將網站轉換為PDF不再有效。

iText

iText的文件不易找到，我們不得已閱讀了一本電子書來獲取我們正在尋找的範例代碼以執行此範例。 不做任何代碼更改，不需額外配置，四行代碼就將一個非常漂亮的PDF渲染得出來，沒有水印，邊距良好。

圖19 - iText渲染的靜態站點

對於這個測試，我們正在使用ESPN.com，一個體育網站，頁面上有大量的CSS、圖片和JavaScript。 鑑於Aspose在簡單測試中不起作用，我們將不再考慮它。 我們將使用上次示範中使用的相同代碼來創建這些捕獲，只是替換網站地址。

作為參考，這是此測試時ESPN的外觀：

圖20 - 體育台在瀏覽器中的完整渲染呈現

比分在頂部，中間屏幕的比賽狀態報告由JavaScript放置，所有定位和顏色由CSS3處理。

IronPDF

IronPDF的渲染能夠忠實地複制和加載動態內容，但看起來似乎頁面是為行動裝置渲染的，內容元素分解為卸單獨段落並瓦片排列。

圖21 - IronPDF渲染的ESPN

SyncFusion

SyncFusion也進行了類似的"行動樣式"渲染，內容縱向鋪排。 然而，我們失去了一些由ESPN網站動態加載的圖片，某些字體格式化也丟失了：

圖22 - SyncFusion渲染的ESPN

iText

對於這個測試，iText拒絕運行，並投上了一個NullReferenceException，防止它嘗試渲染該網站。

最後的測試是生成一個基於網站的具有表單輸入字段的PDF。我寫的簡單新聞訂閱表單可在GitHub存儲庫中找到並使用Firefox中的Bootstrap 5渲染，如下所示：

圖23 - 表單網站在Firefox中

注意：狀態是組合框，電話欄是電話欄，電子郵件是電子郵欄，鞋碼是數字欄。

IronPDF

Iron在這次測試中表現得非常出色，如移動友好的佈局呈現在右上角的三明治選單按鈕中。 在測試版中跨頁面滲透的水印相當煩人，但在完全授權版本中已被去除。

所有文本框字段都呈現在PDF表單字段中，我可以與之互動，但最後的單選按鈕和複選框除外。 文本框在它們上沒有特定的驗證或內容強制，正如它們在瀏覽器中一樣。

圖24 - IronPDF渲染的表單

SyncFusion

SyncFusion 渲染了看來是網站的完整桌面版本，因為不存在三明治選單按鈕。 表單元素呈現在屏幕的方塊、按鈕和盒子中，但都不標準的PDF數據輸入字段。 頁首和頁腳的鏈接，雖然被水印遮住，但可以點擊。

圖25 - SyncFusion渲染的表單網站

iText

iText是三個框架中在渲染內容中的速度最快的。 然而，這速度是有代價的。它們的渲染確實提供了導航用戶可以點擊的錨定標籤，但未抵達原網站。所有來自引導程序的格式化均丟失，所有表單字段均呈現為簡單的框。

圖26 - iText渲染的表單網站