如何刪除PDF文件中的頁面

產品的文件將決定產品長期內能否受開發者喜愛。 當他們深入並需更高階功能時，找那個材料的速度，以及是否有範例幫助教導這些概念。

在這些產品中，我在他們的API文件中搜尋新增數位簽章到PDF的能力。

IronPDF

API 文件清晰且組織良好，左側面板有一個動態過濾的目錄。 右上角的搜索框也包含一個動態過濾，迅速返回幾篇文章介紹提供數位簽章功能的各種組件。 API站點支援淺色和深色模式，這是開發者偏好的功能。

圖15 - IronPDF API 簽名檢索結果

PdfSignature 類文件描述了該物件，但未包含範例程式碼連結。 我在ironpdf.com網站中尋找"簽名"一詞，找到了該 PdfSignature 物件的範例程式碼，其位於 IronPDF Digitally Sign a PDF Example。

Aspose

Aspose的API文件在我搜尋簽名時連結到了他們的 PdfFileSignature 類。 這個頁面，如 IronPDF 的頁面一樣，顯示了 PdfFileSignature 類的細節，但沒包含任何演示或描述該類用途的連結。

我回到 Aspose 文件主頁，位於 Aspose.PDF for .NET文件，然後搜尋簽名。 然後我看到了一份相關文章清單，並點進了位於Aspose Add Signature in PDF的"在PDF文件中新增簽名"文章。

Syncfusion

Syncfusion的PDF文件格式產品的文件頁面位於 Syncfusion PDF File Formats Overview，須在他們的網站點幾次才能找到。 我不需要找遠處就找到簽名樣本，作為文件的首頁。

在Syncfusion網站上，沒有支持數位簽章功能的API文件。

iText

iText 的API文件非常詳盡，並從每個發布版本生成。 這是標準的外觀和感覺，從網上的其他程式庫中習以為常。 搜尋簽名時找到幾個類及其功能周圍的一些很好的描述，但同樣沒有範例連結。

我搜尋iText網站上的簽名範例，但未能找到，反而看到幾篇宣布新合作的部落格文章。

每個工具提供的API都非常描述性，並各自采取不同的方法來給開發者完全存取建立和管理PDF文件內容的能力。 幸運的是，所有這些框架都提供完整的自動補全提示，當您在 Visual Studio 或 Visual Studio Code 等支援自動補全功能的現代程式碼編輯器中使用其工具時，提供很好的行內文件。

IronPDF

IronPDF APIs 使得非常困難和複雜的交互操作變得易如反掌，使用"RenderHtmlAsPDF"等簡化命令，但仍提供對文件建立和內容放置、安全性、元資料和表單的深度存取。 作為開發者，這些API"說出我思考內容呈現的方式"。

IronPDF APIs 使用的名稱和術語使得您在渲染文件或建構文件時清楚。 某些設定的時間屬性是以毫秒為單位的整數，而我更傾向於使用原生的TimeSpan型別。 最後，我希望能看到設定和選項型別和如這樣的現代化流利配置API:

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

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

Dim renderer = New IronPdf.ChromePdfRenderer(Sub(options)
	options.RenderDelay = TimeSpan.FromSeconds(1)
End Sub)

Syncfusion

Syncfusion APIs 清晰且提供非常描述性的控制，關於如何與其轉換工具互動。 這裡沒有捷徑，一切都是必要的，您必須告訴它您正在使用哪些工具，沒有預設值。 設定非常詳細，提供對一切的精細控制，包括磁碟上 WebKit 渲染器的位置。

這些額外配置，儘管在某些安裝中不需要，在過去對於人們造成了問題，在未來的版本中Syncfusion承諾不再存在問題。

Aspose

Aspose API 極度冗長，讓我懷疑是否真的試圖讓開發者更高效。 從網站載入檔案所需的配置數量令人驚訝，十行程式碼或是Syncfusion的两倍（五行）。

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

iText

iText 擁有類似 Aspose 的 API，十分冗長，並允許直接與不同資料型別書寫。但不清楚怎樣創造文件片段。 使用這些 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倉庫獲得，並用Bootstrap 5在Firefox中這樣顯示：

圖23 - Firefox中的表單網站

注意：狀態是一個下拉框，電話字段是一個電話字段，電子郵件是一個電子郵件字段，鞋碼是一個數字字段。

IronPDF

Iron在這次測試中表現突出，快速渲染，呈現類似移動友好的佈局，從右上角的漢堡選單按鈕可見。 測試版中的水印有些惱人，但在完全授權版本中被去除。

所有文字框字段都呈現為可操作的PDF表單字段，除了末尾的單選按鈕和核取方塊。 文字框在瀏覽器中沒有特定的驗證或內容強制。

圖24 - IronPDF 表單渲染

Syncfusion

Syncfusion呈現的是看似完整桌面版本的網站，因為沒有漢堡選單按鈕。 部分表單項目呈現為螢幕上的方塊、按鈕和框，但沒有一個是標準PDF資料輸入字段。 標頭和頁腳上的連結，雖然被水印遮住，但仍然可點擊。

圖25 - Syncfusion 渲染的表單網站

iText

iText 是三個框架中渲染內容最迅速的。 然而，速度是有代價的。其渲染實現了錨標籤的導航功能，但未能抵達原始網站。來自bootstrap的格式化被丟失，且所有表單字段都呈現為普通框。

圖26 - iText 渲染的表單網站