Hi,
we're seeing a problem with XFDF generated by MacOS Adobe Reader for stamp
annotations.
For some stamps, Adobe Reader generates appearance stream data that contain the
number 4294967036
(The Windows version apparently does not !)
When we try to process such XFDF, we get
java.lang.NumberFormatException: For input string: "4294967036"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
~[?:1.8.0_332]
at java.lang.Integer.parseInt(Integer.java:583) ~[?:1.8.0_332]
at java.lang.Integer.parseInt(Integer.java:615) ~[?:1.8.0_332]
at
org.apache.pdfbox.pdmodel.fdf.FDFAnnotationStamp.parseDictElement(FDFAnnotationStamp.java:396)
~[pdfbox-app-2.0.25.jar:2.0.25]
at
org.apache.pdfbox.pdmodel.fdf.FDFAnnotationStamp.parseDictElement(FDFAnnotationStamp.java:380)
~[pdfbox-app-2.0.25.jar:2.0.25]
at
org.apache.pdfbox.pdmodel.fdf.FDFAnnotationStamp.parseDictElement(FDFAnnotationStamp.java:380)
~[pdfbox-app-2.0.25.jar:2.0.25]
at
org.apache.pdfbox.pdmodel.fdf.FDFAnnotationStamp.parseDictElement(FDFAnnotationStamp.java:380)
~[pdfbox-app-2.0.25.jar:2.0.25]
at
org.apache.pdfbox.pdmodel.fdf.FDFAnnotationStamp.parseStreamElement(FDFAnnotationStamp.java:234)
~[pdfbox-app-2.0.25.jar:2.0.25]
at
org.apache.pdfbox.pdmodel.fdf.FDFAnnotationStamp.parseStampAnnotationAppearanceXML(FDFAnnotationStamp.java:174)
~[pdfbox-app-2.0.25.jar:2.0.25]
at
org.apache.pdfbox.pdmodel.fdf.FDFAnnotationStamp.<init>(FDFAnnotationStamp.java:133)
~[pdfbox-app-2.0.25.jar:2.0.25]
at
org.apache.pdfbox.pdmodel.fdf.FDFDictionary.<init>(FDFDictionary.java:211)
~[pdfbox-app-2.0.25.jar:2.0.25]
at org.apache.pdfbox.pdmodel.fdf.FDFCatalog.<init>(FDFCatalog.java:63)
~[pdfbox-app-2.0.25.jar:2.0.25]
at
org.apache.pdfbox.pdmodel.fdf.FDFDocument.<init>(FDFDocument.java:90)
~[pdfbox-app-2.0.25.jar:2.0.25]
Do I blame MacOS Adobe Reader for generating that number when its Windows
brother does not ?
Do I blame Java 8's Integer.parseInt for not being lenient enough ?
Do I blame PDFBox for not using Long ?
Do I blame myself for fudging the last release and not deploying 2.0.26
properly ?
Is there any sensible way to correct such data before trying to process it ?
All the best,
Kai
