我見過有人在網上談論這件事，我被告知要這樣做，但它看起來像iText渲染引擎遠不符合MS詞（openoffice，TeX）。 無論如何，解釋一個.doc並不是微不足道的（J.Spolsky解釋了爲什麼），所以我有點懷疑。我真的想爲一個項目做到這一點，但我在網上找不到任何東西，我認爲最簡單的方法就是模塊化OpenOffice並抓住輸入系統，佈局系統和輸出系統，留在銀行的用戶界面。但是我現在在網上看到的最接近的東西是連接到OpenOffice/MS Office的實時實例，並向它發送命令（讀取.doc，生成PDF）。有沒有人真的用POI讀過.doc文件，並用它創建了一個iText文檔？
你有沒有網上的任何代碼來顯示這個[閱讀.doc - >在文檔中編輯一點（添加一個小表，填空白） - >生成PDF]神話鏈？
我會猜測這只是假設可能。也就是說，聽起來好像有問題的軟件應該這樣做，但實際情況卻大相徑庭。正如您正確地指出DOC和PDF是非常不同的格式，創建DOC作爲PDF進行忠實的一對一翻譯的唯一方法就是打印它並捕獲輸出，就像許多PDF創作者一樣。
POI，和其他軟件，如使用Aspose.Words會讓你閱讀DOC的結構，iText的會讓你創建一個PDF，但必然是在這兩個這意味着一百萬的小弱點和邊緣的情況下任何轉換器的實現肯定是不平凡的。關於我的頭頂，我可以告訴你，iText對分割表中的行的支持很差。在我所研究的項目中，我們必須將行分割表格單元呈現爲一種「離屏PDF圖像」，然後將圖像嵌入到單個表格單元格中。最後一個令人愉快的黑客攻擊，但在開始考慮嵌入式OLE對象，ActiveX控件，自選圖形，從右到左的語言之前，您將很難重現DOC支持的一些更豐富的功能，等等。我們不要忘記，每個版本的Word都會爲DOC引入新功能，並修復舊版本中錯誤的東西。
對於足夠簡單的文檔，您可能可以通過一點努力獲得合理的結果。我從來沒有這樣做，我也不想嘗試，因爲我知道一旦源文檔的複雜性超出了段落和標題，結果就會變得平庸。無論你想要做什麼，我都鼓勵你先找到另一種方式。