轉載請註明出處 https://www.cnblogs.com/majianming/p/9537173.html 項目中須要對訂單生成pdf文件,在不斷的嘗試以後,終於生成了比較滿意的pdf文檔。 簡單介紹一下背景:項目是一個erp項目,docker容器化CentOS 7運行環境,應用打包方式jar,使用itext生成pdfhtml
咱們從後面的三個背景來分析linux
com.itextpdf.text.FontFactoryImp#registerDirectories()
下,咱們發現了這樣一段代碼String windir = System.getenv("windir"); String fileseparator = System.getProperty("file.separator"); if (windir != null && fileSeparator != null) { fontResolver.addFontDirectory(windir + fileseparator + "fonts", BaseFont.NOT_EMBEDDED); } fontResolver.addFontDirectory("/usr/share/X11/fonts", BaseFont.EMBEDDED); fontResolver.addFontDirectory("/usr/X/lib/X11/fonts", BaseFont.EMBEDDED); fontResolver.addFontDirectory("/usr/openwin/lib/X11/fonts", BaseFont.EMBEDDED); fontResolver.addFontDirectory("/usr/share/fonts", BaseFont.EMBEDDED); fontResolver.addFontDirectory("/usr/X11R6/lib/X11/fonts", BaseFont.EMBEDDED); fontResolver.addFontDirectory("/Library/Fonts", BaseFont.EMBEDDED); fontResolver.addFontDirectory("/System/Library/Fonts", BaseFont.EMBEDDED);
也就是說,itext已經把背景分析2中的指定字體路徑的事情作了,只是咱們尚未字體在對應的路徑上 而後咱們再看看其中的這個代碼docker
String windir = System.getenv("windir"); String fileseparator = System.getProperty("file.separator"); if (windir != null && fileSeparator != null) { fontResolver.addFontDirectory(windir + fileseparator + "fonts", BaseFont.NOT_EMBEDDED); }
windir? 比較熟悉windows下變量的人能夠知道,這個是獲取windows系統根路徑的一個環境變量,我是win 10的電腦,獲取的就是C:\Windows。 咱們打開C:\Windows\fonts路徑,會發現都是相關字體文件,也就是解釋了爲何在linux中文沒法顯示的jar包在Windows下能夠正常顯示了——並非在windows下能夠讀取到jar包的字體文件,而是在windows下能夠讀取到系統中的字體文件。 由於這個緣由,天然能夠顯示中文字體;因此,若是要顯示任何自定義的字體,在windows下,咱們能夠將能夠添加到C:\Windows\fonts下;在liunx環境下,添加到對應的路徑下便可。咱們理論上可使用任何一個系統中已經定義的字體。在這裏,咱們選擇了/usr/share/fonts這個路徑,固然這個路徑在CentOS中是不存在的,因此要手動建立,而後將須要的中文字體複製進去windows
由於公司的環境是k8s的docker容器,爲了平時的docker容器部署方便,咱們依然把字體文件放在工程下(與dockerfile同一級),而後使用docker的命令將字體複製到指定路徑下服務器
COPY ./fonts/ /usr/share/fonts/
docker cp命令 | Docker Documentation字體
轉載請註明出處 https://www.cnblogs.com/majianming/p/9537173.htmlspa