We use PDFTron PDFAComplaince to convert and validate PDF/A docs (https://www.pdftron.com/pdfnet/samplecode.html#PDFA).
One of our client is doing validation with PDFBox and is reporting the following issue:
= = = =
3.1.10 : Invalid Font definition, CMapName or WMode is inconsistent
No response (pdfbox validator locked - Maybe, a bug in our validator).
java.lang.NullPointerException at org.apache.pdfbox.pdmodel.font.PDType0Font.getFontWidth(PDType0Font.java:188
= = = =
Unfortunately, we must to validate our documents using PDFBox.
Have you got the possibility to add the missing attributes ?
The above pdfbox exception is ambiguous and indicates that the issue may be a bug in its validator.
Please keep in mind that pdfbox is not a standard for PDF/A validation by any means. If fact it is probably the worst choice for PDF/A validation. All other tools I tried on this file which are considered ‘standard’ or ‘market leading’ are not reporting any issues on the file.
I use ‘standard’ under quotes because there is no standard or perfect PDF/A validator. There is close to 100% probability that no matter what two validators you pick there will be disagreements and there are solid technical reasons why this will not change anytime soon. You would need to look at specific error messages where disagreement arises and decide there is defect and whether the issue is critical for long term archiving.
Since we are not supporting pdfbox, I would suggest moving to another validator, because you will likely run into many other issues (besides the one that you just encountered). If you need a ‘free’ solution, we also offer free PDF/A validation as part of PDF/A Manager CLI Tool - https://www.pdftron.com/pdfamanager/downloads.html).