We Keep Coding

iText 5.5.11 - bold text looks blurry after using PdfCleanUpProcessor

I need to remove some content from an existing pdf created with Jasper Reports in iText 5.5.11 but after running PdfCleanUpProcessor all bold text is blurry.
This is the code I'm using:
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();
As already discussed here downgrading to itext-5.5.4 solves the problem, but in my case itext-5.5.11 is already in use for other reasons and so downgrading is not an option.
Is there another solution or workaround?
This are the pdf files before and after cleaning: BEFORE - AFTER

By comparing the before and after files it becomes clear that for some reason the PdfCleanUpProcessor falsely drops general graphics state operations (at least w, J, and d).
In your before document in particular the w operation is important for the text because a poor man's bold variant is used, i.e. instead of using an actual bold font the normal font is used and the text rendering mode is set to not only fill the glyph contours but also draw a line along it giving it a bold'ish appearance.
The width of that line is set to 0.23333 using a w operation. As that operation is missing in the after document, the default width value of 1 is used. Thus, the line along the contour now is 4 times as big as before resulting in a very fat appearance.
This issue has been introduced in commit d5abd23 (dated May 4th, 2015) which (among other things) added this block to PdfCleanUpContentOperator.invoke:
} 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;
This causes all lineStyleOperators to be dropped while at the same time an attempt was made to store the changed values in the cleanup strategy context. But of course using == for String comparisons in Java usually is a very bad idea, so since this version the line style operators were dropped for good in iText.
Actually this code had been ported from iTextSharp, and in C# == for the string type works entirely different; nonetheless, even in the iTextSharp version these stored values at first glance only seem to have been taken into account if paths were stroked, not if text rendering included stroking along the contour.
Later on in commit 9967627 (on the same day as the commit above) the inner if..else if..else.. has been removed with the comment Replaced PdfCleanUpGraphicsState with existing GraphicsState from itext.pdf.parser package, added missing parameters into the latter, only the disableOutput = true remained. This (also at first glance) appears to have fixed the difference between iText/Java and iTextSharp/.Net, but the line style values still are not considered if text rendering included stroking along the contour.
As a work-around consider removing the lines
} else if (lineStyleOperators.contains(operatorStr)) {
disableOutput = true;
from PdfCleanUpContentOperator.invoke. Now the line style operators are not dropped anymore and the text in your PDF after redaction looks like before. I have not checked for any side effects, though, so please test with a number of documents before even considering using that work-around in production.

Exception when adding a PdfFormField to a big PDF

I am adding a PdfTextFormField over a Table cell using a custom renderer, as per the iText7 example code in CreateFormInTable.java. This works initially, until I create a Table on page 3 or later of the PDF, at which point I'm getting an exception:
Caused by: java.lang.NullPointerException
at com.itextpdf.kernel.pdf.PdfDictionary.get(PdfDictionary.java:552)
at com.itextpdf.kernel.pdf.PdfDictionary.getAsArray(PdfDictionary.java:156)
at com.itextpdf.kernel.pdf.PdfPage.getAnnotations(PdfPage.java:746)
at ...pdf.annot.PdfAnnotation.getPage(PdfAnnotation.java:435)
at ...forms.fields.PdfFormField.regenerateField(PdfFormField.java:1761)
at ...forms.fields.PdfFormField.setValue(PdfFormField.java:1038)
at ...forms.fields.PdfFormField.setValue(PdfFormField.java:999)
at ...forms.fields.PdfFormField.setValue(PdfFormField.java:994)
etc.
It seems fairly easy to reproduce, and I can provide a full code sample if you want, but a simple way to see the problem is to insert:
for (int i=1; i < 2; i++) // Change 2 to 3 and you get an NPE
{
Paragraph para = new Paragraph("Page "+ i);
doc.add( para );
doc.add( new AreaBreak( AreaBreakType.NEXT_PAGE ) );
}
straight after the Document constructor in the aforementioned iText7 Java sample file at:
http://developers.itextpdf.com/examples/form-examples/clone-create-fields-table#2350-createformintable.java
I've tested it on 7.0.1 and 7.0.2, with same result.

Well, currently some of the form-related functionality requires the whole PDF document structure to be in memory to operate. This means that no object can be flushed. But layout's DocumentRenderer flushes the pages when possible. The problem reproduces only for three or more pages because there is a small "window" of unflushed pages.
This is indeed not mentioned in the sample and can be improved in the future. In the current version, to get the desired PDF, you can set the Document to operate in "postpone flushing" mode using the following constructor:
Document doc = new Document(pdfDoc, PageSize.A4, false);

OpenCV 3.0.0 FaceDetect Sample fails

I am trying to get OpenCV running i am using the following
sample code
I get the following Error line displayed:
OpenCV Error: Assertion failed (!empty()) in cv::CascadeClassifier::detectMultiScale, file ..\..\..\..\opencv\modules\objdetect\src\cascadedetect.cpp, line 1580
Exception in thread "main" CvException [org.opencv.core.CvException: cv::Exception: ..\..\..\..\opencv\modules\objdetect\src\cascadedetect.cpp:1580: error: (-215) !empty() in function cv::CascadeClassifier::detectMultiScale
]
at org.opencv.objdetect.CascadeClassifier.detectMultiScale_1(Native Method)
at org.opencv.objdetect.CascadeClassifier.detectMultiScale(CascadeClassifier.java:176)
at org.maxbit.opencv.samples.DetectFaceDemo.run(SampleB.java:29)
at org.maxbit.opencv.samples.SampleB.main(SampleB.java:51)
Can any body tell me what that error means or how to debug this?

I also faced the problem. The problem is in the .getPath() return an absolute path of the format.
Eg: "/C:/Users/projects/FaceDetection/bin/com/face/detection/haarcascade_frontalface_alt.xml".
So change the code like this.
CascadeClassifier faceDecetor = new CascadeClassifier(FaceDetection.class.getResource("haarcascade_frontalface_alt.xml").getPath().substring(1));

This happens usually for two reasons.
Cascade classifier file lbpcascade_frontalface.xml not present at specified path.
Cascade classifier file is corrupted.
To get an error message instead of exception during runtime, try code sample as below. The CascadeClassifier constructor is silent, if it cannot load the cascade classifier XML. The onus is on the developer to call the empty() method and check if classifier is loaded correctly
CascadeClassifier cascade = new CascadeClassifier( CASCADE_CLASSIFIER_PATH );
if ( cascade.empty() ) {
//handler error here
}
Exception you got is from OpenCV native code assertion here.

I ran into this same error running on a Windows box. This sample runs on linux but not Windows.
The problem is in the .getPath() call after getResource() for both the xml file and the image.
The problem is that the URL.getPath() and the URL.getFile() both return an absolute path of the format "/c:/...".
The OpenCV routines choke on this it must be "c:/..." (no leading '/'). This seems like a bug in the early part of version 3.0.0?
I hope this helps, OpenCV for Java seems like a great tool ... but it is a bit frustrating when the examples don't work.

There is a problem with the latest openCV it doesn't work when you have spaces in your path so do this:
String s =CameraPanel.class.getResource("lbpcascade_frontalface.xml").getPath().substring(1);
String[] split = s.split("%20");
StringBuilder stringBuilder = new StringBuilder();
for (int i = 0; i < split.length-1; i++) {
stringBuilder.append(split[i]+" ");
}
stringBuilder.append(split[split.length-1]);
faceDetector = new CascadeClassifier(stringBuilder.toString());

I ran into the same issue: On windows, OpenCV chokes on both the prepended '\' and any whitespace in the path, as both Imad and Aung have noted. My solution is a bit shorter than Imad's:
Change this:
CascadeClassifier faceDecetor = new CascadeClassifier(
getClass().class.getResource("haarcascade_frontalface_alt.xml").getPath());
To this:
CascadeClassifier faceDecetor = new CascadeClassifier(
getClass().class.getResource("haarcascade_frontalface_alt.xml").getPath().substring(1).replaceAll("%20", " "));

For me the simplest solution was:
private void checkboxSelection(String classifierPath) {
// load the classifier(s)
faceCascade.load(classifierPath);
// Did it work?
if (faceCascade.empty()) {
// Try the full path
String resource = getClass().getResource(classifierPath).getPath();
// Discard leading / if present.
if ( resource.startsWith("/")) {
resource = resource.substring(1);
}
faceCascade.load(resource);
}
// now the video capture can start
cameraButton.setDisable(false);
}

I am using openCv 3.4.1
I think there's a bug in CascadeClassifier initializer.
In order to get rid of this error, I must call "load" once again. Hope this solution could help.
cascadeClassifier = new CascadeClassifier(mCascadeFile.getAbsolutePath());
cascadeClassifier.load(mCascadeFile.getAbsolutePath());

I faced problem on Mac (OSX) Java.
CameraFrame.class.getResource("haarcascade_frontalface_alt.xml").getPath().substring(1)
returned "Users/username/Desktop/JavaProjects/Camera/bin/haarcascade_frontalface_alt.xml".
whereas path should start with "/" therefore I appended "/".
face = new CascadeClassifier("/" +
CameraFrame.class.getResource("haarcascade_frontalface_alt.xml").getPath().substring(1));
It works OK now :)

I faced the same problem as well. It is just because the path you gave for 'haarcascade_frontalface_alt2.xml' might be incorrect of not proper. just copy the full path from file explorer and paste it. This solution works for me.
face_cascade = cv2.CascadeClassifier('C:/Users/xyz/FaceDetect/faceId/OpenCV-Python-Series-master/src/cascades/data/haarcascade_frontalface_alt2.xml')

POI Excel Merging Causing "Repaired Records: Format from /xl/styles.xml part (Styles)"

I have merged two excel files using the code specied here
http://www.coderanch.com/t/614715/Web-Services/java/merge-excel-files
this the block applying the styles for my merging cells
if (styleMap != null)
{
if (oldCell.getSheet().getWorkbook() == newCell.getSheet().getWorkbook())
{
newCell.setCellStyle(oldCell.getCellStyle());
}
else
{
int stHashCode = oldCell.getCellStyle().hashCode();
XSSFCellStyle newCellStyle = styleMap.get(stHashCode);
if (newCellStyle == null)
{
newCellStyle = newCell.getSheet().getWorkbook().createCellStyle();
newCellStyle.cloneStyleFrom(oldCell.getCellStyle());
styleMap.put(stHashCode, newCellStyle);
}
newCell.setCellStyle(newCellStyle);
}
}
It all working as expected and going well in generating my XSSFWorkbook.
Problem starting when I try to open it:
I see below error
and my error report contains below
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<recoveryLog xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
<logFileName>error072840_01.xml</logFileName>
<summary>Errors were detected in file 'XYZ.xlsx'</summary>
<repairedRecords summary="Following is a list of repairs:">
<repairedRecord>Repaired Records: Format from /xl/styles.xml part (Styles)</repairedRecord>
</repairedRecords>
</recoveryLog>
After all these my sheet opens up fine but without styles. I know there is a limitation on number of styles to be created and have counted the styles being created and I hardly see 4 created. I even know that this issue is with too many styles.
Unfortunately, POI has support to optimise only HSSFWorkbook (Apache POI delete CellStyle from workbook)
Any help in how to mitigate with this issue will be great.

Well, after debugging bit of POI code and how styles are being applied and so.
Doing below solved the problem
newCellStyle.getCoreXf().unsetBorderId();
newCellStyle.getCoreXf().unsetFillId();

I had the same issue.
You should to minimize instances of styles and fonts because each instance is placed into xl/styles.xml
Make styles and fonts only once for one book.

I had the same issue using the Python library xlxswriter with Pandas. After I stopped trying to use Pandas' date_format specification, I stopped getting the error.
import pandas as pd
data = pd.read_excel('somefile.xlsx')
grp = data.groupby('Property Manager')
for i, (pm, g) in enumerate(grp):
writer = pd.ExcelWriter(p + f.format(pm[:30]), engine='xlsxwriter') #,date_format='%m/%d/%Y')
g[cols].to_excel(writer, sheet_name='Summary', index=False)
writer.save()

Apache POI: changing CellType causes IllegalStateException

Why is it illegal to change cell type in Apache POI? The code bellow causes IllegalStateException: Cannot get a error value from a numeric cell.
Cell mycell = myrow.createCell(0);
// Make it numeric by default.
mycell.setCellType(Cell.CELL_TYPE_NUMERIC);
if (someCondition) {
mycell.setCellType(Cell.CELL_TYPE_STRING); // IllegalStateException
}
Is there perhaps a way around this problem (as in without introducing additional logic)?

Im not sure this is avoiding your "without additional logic" but here goes:
Cell mycell = myrow.createCell(0);
// Make it numeric by default.
int cellType = Cell.CELL_TYPE_NUMERIC;
if (someCondition) {
cellType = Cell.CELL_TYPE_STRING;
}
mycell.setCellType(cellType);
The Javadoc does not state why it would throw an IllegalStateException so I would just avoid it (by doing the above) or go digging in the sourcecode.

Fixed it. After replacing the streaming version (org.apache.poi.xssf.streaming.SXSSFWorkbook) with the non-streaming one (org.apache.poi.xssf.usermodel.XSSFWorkbook) the exception was gone. I'm okay with XSSFWorkbook since I'm filling XLSX with only a couple of lines.