與 IronPDF 的產品比較

產品的說明文件將決定該產品在開發人員心目中的長期形象。 當他們深入了解並需要更進階的功能時，他們能多快找到這些資料，以及是否有提供範例來幫助教授這些概念。

在每個產品中，我都搜尋了它們的 API 文件，以尋找在 PDF 中加入數位簽章的功能。

IronPDF。。

API 文件清晰且組織良好，左側面板的內容表具有即時篩選功能。 右上方的搜尋方塊也包含一個即時篩選器，並快速傳回數篇關於提供 Signature 功能的各種元件的文章。 API 網站有明暗兩種模式，這是開發人員偏好的好功能。

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

PdfSignature 類別文件描述了物件，但不包含任何範例程式碼的連結。 我在 IronPdf.com 網站搜尋"簽署"，並在 IronPDF 數位簽署 PDF 實例找到引用 PdfSignature 物件的範例程式碼。

Aspose

當我搜尋 Signature 時，Aspose API 文件將我連結到他們的 PdfFileSignature 類別。 本頁面和 IronPDF 的一樣，顯示了 PdfFileSignature 類的細節，但不包含任何演示連結，也不描述如何使用該類。

我回到 Aspose 文件基頁 Aspose PDF for .NET 文件 並搜尋簽名。 接下來我看到相關文章的清單，並點選 Aspose Add Signature in PDF 網站中的"在 PDF 檔案中加入簽名"一文。

SyncFusion。。

SyncFusion 的 PDF 檔案格式產品的基本文件頁面在 Syncfusion PDF 檔案格式總覽，在他們的網站上點幾下就找到了。 我沒有找太遠就找到了簽名樣本作為文件的頭版。

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

iText。

iText 的 API 說明文件非常詳盡，並且從每個已發行版本中產生。 這是一種標準的外觀和感覺，您可以從網際網路上的其他圖書館看到。 搜索簽名找到了幾個類別，圍繞這些功能有一些很好的描述，但同樣沒有樣本的連結。

我在 iText 網站上搜尋 Signature 樣本，但無法找到，取而代之的是幾篇宣佈新合作關係的部落格文章。

每種工具所提供的 API 都非常具說明性，而且每種工具都有自己的方法，讓開發人員可以完全存取 PDF 文件的內容。 值得慶幸的是，當您在 Visual Studio 或 Visual Studio Code 等提供自動完成功能的現代程式碼編輯器中使用這些工具時，所有的框架都有完整的自動完成提示，可提供絕佳的線上文件。

IronPDF。。

IronPDF API 透過"RenderHtmlAsPdf"這樣的簡化指令，讓非常困難和複雜的互動變得容易，但仍能深入存取文件的內容、安全性、元資料和表單的建立與放置。 身為開發人員，這些 API"說明了我對於呈現內容的思考方式"。

IronPDF API 使用的名稱和術語可讓您清楚地瞭解您正在渲染文件或建立文件。 某些設定上的時間屬性是代表毫秒的整數，而我希望使用原生的 TimeSpan 類型。 最後，我希望看到"設定"和"選項"類型能像這樣提供現代流暢的設定 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 的 API 與 Aspose 相似，非常冗長，並允許直接互動寫入具有不同資料類型的文件，但不清楚如何建立文件的區段。 由於 API 如此明確，而文件品質又不高，因此使用 iText 工作充其量也只能說是困難重重。

參考網站非常簡單，沒有 CSS，只有帶有連結和圖片的文字。

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

IronPDF。。

這只是執行簡單的三行程式碼，效能看起來還不錯，只有 835 毫秒。 然而，當我打開 PDF 時，我發現所有的圖片都沒有包含在渲染中，這在預設配置下是一個令人失望的結果。

經過一番探索之後，我了解到我可以加入一個渲染延遲，有了這個設定，我就可以渲染出包含頁面上適當圖片的 PDF。

使用工具的測試版本時，會在渲染的 PDF 中加入水印。 在完全授權版本中，不會出現此水印。

圖 17 - IronPDF 靜態網站的渲染結果

SyncFusion。。

SyncFusion 是一次令人好奇又困惑的旅程。他們的文件提到幾種不同的方式來呈現和傳送 HTML 與 PDF，其中有不同的版本號碼和不同的框架，需要不同的程式碼和設定，以及安裝二進位工具才能正常運作。

和 IronPDF 演示一樣，SyncFusion 沒有為頁面渲染圖片，交付的 PDF 邊界非常小。

使用工具的測試版本時，會在渲染的 PDF 中加入水印。 在完全授權版本中，不會出現此水印。

圖 18 - 靜態網站的 SyncFusion 渲染。

Aspose

Aspose 對於如何使用他們的工具有一套非常清楚的說明。 然而，根據其網站上將網站轉換為 PDF 的 說明，他們有一個重大的 bug，導致該功能無法運作。 此外，他們的可將網站轉換為 PDF 的線上工具已無法運作。

iText。

iText 的說明文件並不是那麼容易找到，我們必須閱讀一本電子書才能得到我們想要的範例程式碼來執行這個範例。 在沒有程式碼變更、沒有額外配置和四行程式碼的情況下，我們渲染了一個非常好看的 PDF，沒有水印，邊界也很好。

圖 19 - iText 靜態網站的渲染。

在這個測試中，我們使用 ESPN.com，這是一個體育網站，頁面上有大量的 CSS、圖片和 JavaScript。 鑑於 Aspose 在簡單的測試中沒有發揮功能，我們將跳過它們繼續前進。 我們將使用與上一個示範相同的程式碼來建立這些擷取內容，只是將網站位址換掉。

以下是本次測試時 ESPN 的外觀，以供參考：

圖 20 - ESPN.com 在瀏覽器中的完整呈現

螢幕上方的分數和中間的遊戲狀態報告使用 JavaScript 放置，所有定位和顏色均使用 CSS3 處理。

IronPDF。。

IronPDF 的渲染能夠忠實複製並載入動態內容，然而，看起來好像是針對行動裝置渲染的頁面，內容元素被分割成獨立的片段並鋪排成塊狀。

圖 21 - IronPDF 渲染的 ESPN

SyncFusion。。

SyncFusion 進行了類似"行動風格"的渲染，將內容垂直平鋪。 但是，我們遺失了 ESPN 網站動態載入的幾張圖片，而且部分字型格式也遺失了：

圖 22 - SyncFusion 渲染的 ESPN

iText。

在此測試中，iText 拒絕執行，並產生 NullReferenceException，使其無法嘗試渲染網站。

最後的測試是以網站為基礎，產生附有表單輸入欄位的 PDF。我寫的簡單電子報登錄表單可以在 GitHub 套件庫中找到，在 Firefox 中使用 Bootstrap 5 的渲染效果是這樣的：

圖 23 - Firefox 中的表單網站

注意：State 是組合方塊，Phone 欄位是電話欄位，Email 是電子郵件欄位，Shoe Size 是數字欄位。

IronPDF。。

Iron 在這項測試中確實大放異彩，以類似行動友善的版面快速呈現，右上方的漢堡包功能表按鈕就是明證。 在測試版本中，橫跨頁面的水印令人討厭，但在完全授權版本中則會移除。

除了最後的單選按鈕及複選框之外，所有的文字方塊欄位都會呈現成我可以互動的 PDF 表單欄位。 文字方塊與瀏覽器一樣，沒有特定的驗證或內容強制執行。

圖 24 - IronPdf 表單的渲染結果

SyncFusion。。

SyncFusion 渲染的似乎是完整的桌面版網站，因為沒有出現漢堡包功能表按鈕。 渲染的表單元素顯示為螢幕上的方塊、按鈕和方塊，但它們都不是標準的 PDF 資料輸入欄位。 頁頭和頁尾的連結雖然被水印遮住，但仍可點選。

圖 25 - 由 SyncFusion 渲染的表單網站

iText。

iText 是這三個框架中渲染內容速度最快的。 然而，這種速度是有代價的。他們的渲染確實提供了錨標籤，點擊後能夠導航，但卻無法到達原始網站。bootstrap 的所有格式都已遺失，所有表單欄位都呈現為普通方塊。

圖 26 - iText 渲染的表單網站