iTextの5.5.11 - 太字のテキストは、私はiTextの5.5.11でジャスパーレポートで作成した既存のPDFからではなく、すべての太字テキストがぼやけてPdfCleanUpProcessorを実行した後、いくつかのコンテンツを削除する必要がPdfCleanUpProcessor

Question

を使用した後にぼやけて見えます。

これは私が使用しているコードです：

PdfReader reader = new PdfReader("input.pdf"); 
PdfStamper stamper = new PdfStamper(reader, new FileOutputStream("output.pdf")); 
List<PdfCleanUpLocation> cleanUpLocations = new ArrayList<PdfCleanUpLocation>(); 

cleanUpLocations.add(new PdfCleanUpLocation(1, new Rectangle(0f, 0f, 595f, 680f))); 

PdfCleanUpProcessor cleaner = new PdfCleanUpProcessor(cleanUpLocations, stamper); 
cleaner.cleanUp(); 

stamper.close(); 
reader.close(); 

すでに述べたようにiTextの-5.5.4へhere格下げを検討して問題を解決するが、私の場合にはiTextの-5.5.11は、他のためにすでに使用されています理由やダウングレードはオプションではありません。

別のソリューションまたは回避策はありますか？

この清掃前と後のPDFファイルです：BEFORE - それはいくつかの理由でPdfCleanUpProcessorが誤って一般的なグラフィック状態の操作を低下することが明らかになっ前と後のファイルを比較することによってAFTER

Answer 1

（少なくとも、ワット、J、及びD）。あなたの前に文書で

---

貧乏人の大胆バリアントが使用されているので、特にワット操作、すなわち代わりに通常のフォントが使用されている実際の太字フォントを使用するのでは、テキストのために重要であり、テキストレンダリングモードは、グリフの輪郭を塗りつぶすだけでなく、それに沿って線を描き、太字の外観を与えるように設定されています。

この行の幅は、wの操作を使用して0.23333に設定されています。その操作が後の文書に欠けているとおり、1のデフォルトの幅の値が使用されます。したがって、輪郭に沿った線は今や4倍大きくなり、非常に太った外観になる。

---

この問題はPdfCleanUpContentOperator.invokeにこのブロックを追加した（とりわけ）d5abd23（日付月4日、2015）コミットで導入されました：

} else if (lineStyleOperators.contains(operatorStr)) { 
    if ("w" == operatorStr) { 
     cleanUpStrategy.getContext().setLineWidth(((PdfNumber) operands.get(0)).floatValue()); 
    } else if ("J" == operatorStr) { 
     cleanUpStrategy.getContext().setLineCapStyle(((PdfNumber) operands.get(0)).intValue()); 
    } else if ("j" == operatorStr) { 
     cleanUpStrategy.getContext().setLineJoinStyle(((PdfNumber) operands.get(0)).intValue()); 
    } else if ("M" == operatorStr) { 
     cleanUpStrategy.getContext().setMiterLimit(((PdfNumber) operands.get(0)).floatValue()); 
    } else if ("d" == operatorStr) { 
     cleanUpStrategy.getContext().setLineDashPattern(new LineDashPattern(((PdfArray) operands.get(0)), 
       ((PdfNumber) operands.get(1)).floatValue())); 
    } 

    disableOutput = true; 

これがでている間、すべてのlineStyleOperatorsが廃棄されます変更された値をクリーンアップ戦略コンテキストに格納しようとしたのと同時に、しかし、Javaで==Stringのための比較を使用して、もちろん、通常は非常に悪い考えですので、このバージョン以降のラインスタイルの演算子は、iTextので良いのために落とされました。

実際にはこのコードはiTextSharpから移植されており、stringタイプのC＃==では全く異なる働きをしています。それにもかかわらず、iTextSharpバージョンであっても、一見してこれらの保存された値は、テキストレンダリングが輪郭に沿ってストロークを含む場合ではなく、パスがストロークされた場合にのみ考慮されたように見えます。後でオン

内側if..else if..else..はitext.pdf.parserパッケージからGraphicsState既存とPdfCleanUpGraphicsState置き換えコメントで除去された（上記のコミットと同じ日に）9967627コミットは、残っのみdisableOutput = true、後者に欠けているパラメータを追加しました。 iText/JavaとiTextSharp/.Netの違いは固定されているように見えますが、テキストレンダリングで輪郭に沿ってストロークが入っていれば、ラインスタイルの値はまだ考慮されていません。回避策として

---

がPdfCleanUpContentOperator.invokeからライン

} else if (lineStyleOperators.contains(operatorStr)) { 
    disableOutput = true; 

を削除することを検討します。これでラインスタイルの演算子はもはや削除されず、変更後のPDFのテキストは前と同じようになります。私は副作用を確認していませんので、生産現場でその回避策を検討する前に、いくつかの文書でテストしてください。