I'm using iText (in the latest version 5.4.4) for a generic print of user interfaces.
I have a Problem on some UIs, getting a NullPointerException:
23.10.2013 14:53:23.066 - ERROR -Container.doAdd()
com.itextpdf.text.DocumentException: java.lang.NullPointerException
...
Caused by: java.lang.NullPointerException
at com.itextpdf.text.pdf.ColumnText.setSimpleVars(ColumnText.java:312)
at com.itextpdf.text.pdf.ColumnText.setACopy(ColumnText.java:305)
at com.itextpdf.text.pdf.ColumnText.duplicate(ColumnText.java:294)
at com.itextpdf.text.pdf.PdfPCell.<init>(PdfPCell.java:255)
at com.itextpdf.text.pdf.PdfPRow.<init>(PdfPRow.java:131)
at com.itextpdf.text.pdf.PdfPTable.<init>(PdfPTable.java:261)
at com.itextpdf.text.pdf.ColumnText.setSimpleVars(ColumnText.java:347)
at com.itextpdf.text.pdf.ColumnText.setACopy(ColumnText.java:305)
at com.itextpdf.text.pdf.ColumnText.duplicate(ColumnText.java:294)
at com.itextpdf.text.pdf.PdfPCell.getMaxHeight(PdfPCell.java:968)
at com.itextpdf.text.pdf.PdfPRow.calculateHeights(PdfPRow.java:209)
at com.itextpdf.text.pdf.PdfPRow.getMaxHeights(PdfPRow.java:592)
at com.itextpdf.text.pdf.PdfPTable.getRowHeight(PdfPTable.java:990)
at com.itextpdf.text.pdf.PdfPTable.getRowHeight(PdfPTable.java:971)
at com.itextpdf.text.pdf.ColumnText.goComposite(ColumnText.java:1821)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:882)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:877)
at com.itextpdf.text.pdf.PdfPRow.splitRow(PdfPRow.java:736)
at com.itextpdf.text.pdf.ColumnText.goComposite(ColumnText.java:1662)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:882)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:877)
at com.itextpdf.text.pdf.ColumnText.go(ColumnText.java:866)
at com.itextpdf.text.pdf.PdfDocument.addPTable(PdfDocument.java:2602)
at com.itextpdf.text.pdf.PdfDocument.add(PdfDocument.java:727)
... 24 more
After days of debugging my own code and the code of iText, I think I found the responsible line in class com.itextpdf.text.pdf.PdfPRow line 699:
newCells[k].setColumn(null);
I removed this line in the iText-API and the NullPointer does not appear any more. Then the program generates a PDF again, but there still is a problem that there is to many vertical space, which i couldn't fix yet.
Does anybody have the same Problem? Is it a bug in iText?
Thanks for help!
MaKu
Related
I'm trying to build an uberjar using lein uberjar. During compiling, the following gets thrown:
Exception in thread "main" java.lang.NullPointerException, compiling:(/tmp/form-init8223412427040046857.clj:1:73)
at clojure.lang.Compiler.load(Compiler.java:7391)
at clojure.lang.Compiler.loadFile(Compiler.java:7317)
at clojure.main$load_script.invokeStatic(main.clj:275)
at clojure.main$init_opt.invokeStatic(main.clj:277)
at clojure.main$init_opt.invoke(main.clj:277)
at clojure.main$initialize.invokeStatic(main.clj:308)
at clojure.main$null_opt.invokeStatic(main.clj:342)
at clojure.main$null_opt.invoke(main.clj:339)
at clojure.main$main.invokeStatic(main.clj:421)
at clojure.main$main.doInvoke(main.clj:384)
at clojure.lang.RestFn.invoke(RestFn.java:421)
at clojure.lang.Var.invoke(Var.java:383)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.Var.applyTo(Var.java:700)
at clojure.main.main(main.java:37)
Caused by: java.lang.NullPointerException
at clojure.string$lower_case.invokeStatic(string.clj:217)
at clojure.string$lower_case.invoke(string.clj:213)
at kappa.joke_classifier$is_jokable_QMARK_.invokeStatic(joke_classifier.clj:32)
at kappa.joke_classifier$is_jokable_QMARK_.invoke(joke_classifier.clj:29)
at kappa.core$maybe_joke.invokeStatic(core.clj:47)
at kappa.core$maybe_joke.invoke(core.clj:45)
at clojure.core$run_BANG_$fn__7276.invoke(core.clj:7393)
at clojure.lang.PersistentVector.reduce(PersistentVector.java:341)
at clojure.core$reduce.invokeStatic(core.clj:6544)
at clojure.core$run_BANG_.invokeStatic(core.clj:7388)
at clojure.core$run_BANG_.invoke(core.clj:7388)
at kappa.core$run.invokeStatic(core.clj:58)
at kappa.core$run.invoke(core.clj:53)
at kappa.core$_main.invokeStatic(core.clj:66)
at kappa.core$_main.doInvoke(core.clj:61)
at clojure.lang.RestFn.invoke(RestFn.java:397)
at clojure.lang.Var.invoke(Var.java:375)
at user$eval5.invokeStatic(form-init8223412427040046857.clj:1)
at user$eval5.invoke(form-init8223412427040046857.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6927)
at clojure.lang.Compiler.eval(Compiler.java:6917)
at clojure.lang.Compiler.load(Compiler.java:7379)
... 14 more
The code using string/lower-case looks as follows:
(defn is-jokable? [msg]
(and
(> 30 (count msg))
(= :positive (.classify classifier (str/lower-case msg)))
(< 1 (:positive (.probabilities classifier (str/lower-case msg))))))
As can be seen from the stack trace, my -main function calls a function that eventually calls is-jokable, and str/lower-case seems to be called with nil. If I understand correctly this is because of the AOT compilation happening for uberjars, but I'm not quite sure why exactly this problem occurs... I've already tried to read up on AOT, but didn't find anything helpful. Can you explain the inner workings of AOT to me?
I'm almost embarrassed I have posted this, it must have been too late in the night... ;)
I got completely distracted by the compiling and invokeStatic hints in the stacktrace, and just now found that this was indeed an everyday bug where I expected a map to contain a key/value pair that wasn't existent, leading to nil being passed to the function in question.
Thanks for the helpful comments!
I am fetching some problem when I trying to print Arabic letter by using DirectPrint bean. This is a pjc. English fonts are printed fine, but when I want to print Arabic there is showing a exception below:
Exception in thread "main" java.lang.RuntimeException: Not yet implemented
at org.pdfbox.pdmodel.font.PDType0Font.drawString(PDType0Font.java:75)
at org.pdfbox.pdfviewer.PageDrawer.showCharacter(PageDrawer.java:160)
at org.pdfbox.util.PDFStreamEngine.showString(PDFStreamEngine.java:409)
at org.pdfbox.util.operator.ShowTextGlyph.process(ShowTextGlyph.java:80)
at org.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:452)
at org.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:215)
at org.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:174)
at org.pdfbox.pdfviewer.PageDrawer.drawPage(PageDrawer.java:104)
at org.pdfbox.pdmodel.PDPage.print(PDPage.java:741)
at sun.print.RasterPrinterJob.printPage(RasterPrinterJob.java:1936)
at sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1431)
at sun.print.RasterPrinterJob.print(RasterPrinterJob.java:1247)
at dsd.printing.DirectPrint.main(DirectPrint.java:842)
Please help to solve this issue.
Seems like the Arabic characters are not implemented to be converted by the pdfbox library you're using.
What version of PDFBox you are using? What I see from here:
Exception in thread "main" java.lang.RuntimeException: Not yet implemented
at org.pdfbox.pdmodel.font.PDType0Font.drawString(PDType0Font.java:75)
That it says PDType0Font class and drawString method straightly throws 'Not yet implemented' exception but i.e. if I check one of the latest version (i.e. 1.8.10) I can see the method implemented: here
If I would be I would try to change the version of pdfbox library and try again.
EDIT: Thanks to Tilman, latest version info from his comment: 2.0 has been released friday, it should be available for maven: mvnrepository.com/artifact/org.apache.pdfbox/pdfbox
I recently updated my app and there is one exception that occurs a lot. When I look at Crashlytics summary I saw this stacktrace:
[Fatal Exception: java.lang.NullPointerException]
com.company.app.model.ClassA.method1
com.company.app.model.ClassB.method2
com.company.app.view.ClassB.onTouch
android.view.View.dispatchTouchEvent (View.java:7241)
android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:2174)
android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:1875)
android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:2174)
.....
From my understanding, there is no line number shown on the top 3 lines because I use Proguard to obfuscate the app.
But what baffled me is that, it is not possible that ClassA.method1 is called directly or indirectly by ClassB.method2 (I have checked it multiple times). So now I am stuck. Does this mean that the name of methods shown here is inaccurate? And if that is the case, how should I proceed?
Thank you.
I'm using the owl2java plugin to generate Java code from an Ontology file. But I'm always getting de same error.
Exception in thread "main" com.hp.hpl.jena.ontology.ConversionException: Cannot convert node http://www.w3.org/2002/07/owl#bottomObjectProperty to TransitiveProperty
at com.hp.hpl.jena.ontology.impl.TransitivePropertyImpl$1.wrap(TransitivePropertyImpl.java:66)
at com.hp.hpl.jena.enhanced.EnhNode.convertTo(EnhNode.java:142)
at com.hp.hpl.jena.enhanced.EnhNode.convertTo(EnhNode.java:22)
at com.hp.hpl.jena.enhanced.Polymorphic.asInternal(Polymorphic.java:54)
at com.hp.hpl.jena.enhanced.EnhNode.viewAs(EnhNode.java:92)
at com.hp.hpl.jena.enhanced.EnhGraph.getNodeAs(EnhGraph.java:135)
at com.hp.hpl.jena.ontology.impl.OntModelImpl$SubjectNodeAs.map1(OntModelImpl.java:3040)
at com.hp.hpl.jena.ontology.impl.OntModelImpl$SubjectNodeAs.map1(OntModelImpl.java:3033)
at com.hp.hpl.jena.util.iterator.Map1Iterator.next(Map1Iterator.java:35)
at com.hp.hpl.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:68)
at com.hp.hpl.jena.util.iterator.UniqueExtendedIterator.nextIfNew(UniqueExtendedIterator.java:61)
at com.hp.hpl.jena.util.iterator.UniqueExtendedIterator.hasNext(UniqueExtendedIterator.java:69)
at com.hp.hpl.jena.util.iterator.NiceIterator.asList(NiceIterator.java:185)
at com.hp.hpl.jena.util.iterator.NiceIterator.toList(NiceIterator.java:159)
at de.incunabulum.owl2java.core.generator.OwlReader.handleProperties(OwlReader.java:862)
at de.incunabulum.owl2java.core.generator.OwlReader.generateJModel(OwlReader.java:457)
at de.incunabulum.owl2java.core.JenaGenerator.generate(JenaGenerator.java:65)
at onto.main.main(main.java:99)
I have no idea about what I'm doing wrong. Any Ideas?
Thanks you a lot.
I looked at the top line on your exception, and see com.hp.hpl.jena.ontology.impl.TransitivePropertyImpl.
Googling for that leads to a version of the source code. It may not be exactly the same version as you're using, but is probably close enough to be informative. Reading the code leads to these questions:
Does your Model have a profile? It must.
Does the profile support Transitivity? It must.
Are you combining Transitive with something else that it's incompatible with?
I frequently get what appears to be a stackoverflow error ;-) from YUICompressor. The following is the first part of thousands of error lines that come from attempting to compress a 24074 byte css stylesheet (not the "Caused by java.lang.StackOverflowError about 8 lines down):
iMac1:src jas$ min ../style2.min.css style2.css
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:21)
Caused by: java.lang.StackOverflowError
at java.lang.Character.codePointAt(Character.java:2335)
at java.util.regex.Pattern$CharProperty.match(Pattern.java:3344)
at java.util.regex.Pattern$Branch.match(Pattern.java:4114)
... (plus 1021 more error lines)
The errors happen usually after adding a couple of lines to the file getting compressed. The css is fine, and works perfectly in the uncompressed format. I don't see a particular pattern to the types of selectors added to the file that cause the errors. In this case, adding the following selector to a previously compressible file resulted in the errors:
#thisisatest
{
margin-left:87px;
}
I am wondering if there is perhaps a flag to java to enlarge the stack that might help. Or if that is not the problem, what is?
EDIT:
As I was posting this question, it dawned on me that I should check the java command to see if there was a parameter to enlarge the stack. Turns out that it is -Xssn, where "n" is a parameter to indicate the stack size. Its default value is 512k. So I tried 1024k but that still led to the stackoverflow. Trying 2048k works however, and I think this could be the solution.
EDIT 2:
While I no longer use this method for minification any longer, to be more specific here is the full command (which I have set up as a shell alias), showing how the -Xss2048k parameter is used:
java -Xss2048k -jar ~/Documents/RepHunter/Website\ Materials/Code/Third\ Party\ Libraries/YUI\ Compressor/yuicompressor-2.4.8.jar --type css -o
As posted in my edit, the solution was to add the parameters to the java command. The clue was the error line at the 5-th "at" line, as follows:
at com.yahoo.platform.yui.compressor.Bootstrap.main(Bootstrap.java:21)
Caused by: java.lang.StackOverflowError
Seeing that the issue was a "StackOverlowError" ;-) gave the suggestion to try to increase the stack size. The default is 512k. My first try of 1024k did not work. However increasing it to 2048k did work, and I have had no further issues.