[[393772]]

關于生成PDF的需求大部分要放在服務端實現(xiàn)，那么前端是否可以生成PDF呢?

本文目的：

• 記錄一種新的前端生成PDF的技術
• 記錄一種CMS配置化PDF方案的猜想

前端市場中的PDF

這是一個常見的需求，那么就一定有一些現(xiàn)成的技術方案。一種是基于服務端的實現(xiàn)，一種是基于客戶端的實現(xiàn)。

相對于服務端來說，iText、wkhtmltopdf、prince這三個都是后端生成pdf的工具?？上н@三個都沒有node api。

相對于客戶端而言，最常見的就是Html轉化方案。如JSPDF技術。

此方案的邏輯是：

• 將DOM樹轉換為canvas對象，可使用html2canvas完成
• 將canvas轉換為圖片，可使用canvas.toDataURL完成
• 將圖片轉換為PDF，可使用jsPDF完成

此方案的弊端也比較明顯：

• 生產(chǎn)的PDF比較模糊，質量不高
• 瀏覽器兼容性，對css樣式支持不夠，比如陰影
• 分頁效果不理想，會出現(xiàn)斷層、缺失等問題
• 如果HTML中有外鏈圖片，無法生成
• 由于第一步是通過DOM去生成canvas，所以針對特別長的報告，DOM尚未加載完便點擊下載時，會造成報告生成問題

還有一種方案是依靠瀏覽器自帶的打印window.print，此方案的重點在于CSS樣式控制。如果你想要實現(xiàn)改變頁面大小、邊距、設置頁眉頁腳等等效果，可能還需要Prince(應用程序，需要安裝)。

最后來說一下pdfmake技術，純js技術實現(xiàn)PDF的生成，提供服務端生成和客戶端生成方案，可以說是非常便捷。還提供了動態(tài)演示文檔，你可以自由的拼接內容。

我就是被這個頁面“征服”的。它可以自定義實現(xiàn)頁眉、頁腳定制化、封面定制化、水印設置、PDF加密等等。而且它的使用也非常方便只需要兩個js即可，一個是pdfmake.js,另一個是字體文件vfs_fonts.js。

同樣它的弊端也特別明顯，文本元素沒有內邊距，樣式較局限，沒有html那么靈活。相對于其他技術而言，對JS程序員來說是非常的友好了，比較重要的是3年以來一直有人在維護?；久總€月都有更新。

CMS方案猜想

關于cms的理解，可以自行百度，而對于我而言，cms就是配置化。之前寫過一篇關于表單的CMS技術方案，是相對于比較成熟的方案。解決了商品配置，app動態(tài)顯示的難題。缺點就是牽一發(fā)動全身，一直沒有時間去更新、填充新的規(guī)則。

關于CMS-PDF的猜想，也是為了解決PDF模版定制化的問題。平常開發(fā)一個pdf模版可能需要一個團隊一個月的時間，CMSPDF要做的就是縮短開發(fā)時間，提高開發(fā)效率，提供可配置化方案。

想要實現(xiàn)這個方案，首頁考慮的是什么，是我們使用的方式和要達到的效果。通俗點，就是一套數(shù)據(jù)代表一個模版，而這套數(shù)據(jù)的生成就是靠我們配置(點點點)。那么我們要考慮的問題就明確了：

• 分析需求pdf的樣式，解析出模塊類型
• 建立模版與接口數(shù)據(jù)的關聯(lián)關系(橋梁)
• 建立模版綁定關系

pdfmake提供了一些很好的api，方便我們一邊設計模塊，一邊查看效果。例如，我們想要左邊配置，右邊預覽。

需要注意的一點就是pdfmake默認不支持中文，需要你自己尋找pdf報告所需字體，并且字體的一些屬性，比如粗體、斜體也需要字體支持。

此方案難點在于模塊類型的設計，你需要建立頁面顯示數(shù)據(jù)結構與pdfmake代碼規(guī)則數(shù)據(jù)結構之間的聯(lián)系。對模塊類型，沿用pdfmake的就行，只需要在其上在封裝一層即可。

比較復雜的是表格的樣式設計，比如你怎么配置表格每條邊線的樣式，并且與服務端返回數(shù)據(jù)之間建立關系。所以說對細微樣式這塊比較難搞。

此方案還未落地，但不失為一個很好實踐方案。對樣式要求不是特別高的可以嘗試一下。