1 回答

TA貢獻(xiàn)1809條經(jīng)驗(yàn) 獲得超8個(gè)贊
這是 PDFBox 中的一個(gè)錯(cuò)誤。
(好吧,您的代碼中也存在問題,但手頭問題的原因是基于 PDFBox。)
錯(cuò)誤
問題是PDColor.toRGB()
調(diào)用
fillColorRgb = filledPath.getValue().toRGB();
損壞有問題的特定顏色的顏色值本身!
所討論的顏色空間是分離顏色空間。因此,PDColor.toRGB()
調(diào)用PDSeparation.toRGB(float[])
使用其components
成員作為參數(shù)。
如果給定參數(shù)的 RGB 值尚未緩存在顏色空間中,PDSeparation.toRGB(float[])
則評(píng)估給定參數(shù)的 RGB 值tintTransform
。對(duì)于有問題的色彩空間,色調(diào)變換是一個(gè)PDFunctionType0
實(shí)例。因此,PDFunctionType0.eval(float[])
被稱為。
不幸的是PDFunctionType0.eval(float[])
,假設(shè)它可以將數(shù)組參數(shù)input
用于自己的目的:
input[i] = clipToRange(input[i], domain.getMin(), domain.getMax());input[i] = interpolate(input[i], domain.getMin(), domain.getMax(), encodeValues.getMin(), encodeValues.getMax());input[i] = clipToRange(input[i], 0, sizeValues[i] - 1);
但是這個(gè)數(shù)組是原來的PDColor
成員components
。因此,此評(píng)估將顏色對(duì)象的單個(gè)分量從 0.172 更改為 43.688。
后來toRGB
對(duì)該顏色的調(diào)用找到了 43.688(或由于進(jìn)一步不需要的變化而導(dǎo)致的其他值),它遠(yuǎn)遠(yuǎn)超出了最大值 1.0,因此他們將其裁剪為 1.0 并從那里進(jìn)行轉(zhuǎn)換。但是該顏色空間中帶有 1.0 分量的顏色正是用于前景文本的顏色。因此,您的代碼認(rèn)為背景和前景是相同的。
一種解決方法
要解決此問題,PDFunctionType0.eval(float[])
應(yīng)重寫方法以不寫入其參數(shù)數(shù)組。一個(gè)快速的方法是添加
input = input.clone();
在該方法的頂部PDFunctionType0.eval(float[])
。
您的代碼中的問題
您的方法getTextPositionCenterPoint
使用頁面旋轉(zhuǎn)來確定給定的基線中心TextPosition
。但是,這僅適用于頁面旋轉(zhuǎn)后垂直繪制的文本。但是,對(duì)于您的文檔,情況并非如此。因此,您需要分析文本矩陣以了解文本的實(shí)際方向,而不是頁面旋轉(zhuǎn)。
不過,這不會(huì)對(duì)您的情況產(chǎn)生太大影響,因?yàn)?code>TextPosition.getWidth()您用作字符寬度的值也是根據(jù)頁面旋轉(zhuǎn)計(jì)算的。由于相關(guān)頁面未旋轉(zhuǎn),但文本方向旋轉(zhuǎn)了 90°,因此TextPosition.getWidth()
始終返回 0...您可能希望使用getWidthDirAdj()
...
添加回答
舉報(bào)