You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "Tilman Hausherr (JIRA)" <ji...@apache.org> on 2016/02/10 22:12:18 UTC
[jira] [Comment Edited] (PDFBOX-3024) Preflight validation call
PDType0Font.clear at the wrong time
[ https://issues.apache.org/jira/browse/PDFBOX-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141663#comment-15141663 ]
Tilman Hausherr edited comment on PDFBOX-3024 at 2/10/16 9:11 PM:
------------------------------------------------------------------
This NPE in 1.8 is a real mystery. Sometimes, in ContentStreamWrapper.validText, the font has a descendantFont that is not null. It calls {{fontContainer.checkGlyphWith(cid)}} and in that method, the descendantFont of that same font (I printed out the hashcode) is null. For some reason, my debugger doesn't work properly so I used debug output.
And this happens only at the second page, and only if the first page is there too. It doesn't work if only one page is checked.
was (Author: tilman):
This NPE in 1.8 is a real mystery. Sometimes, in ContentStreamWrapper.validText, the font has a descendantFont that is not null. It calls {{fontContainer.checkGlyphWith(cid)}} and in that method, the descendantFont of that same font (I printed out the hashcode) is null. For some reason, my debugger doesn't work properly so I used debug output.
> Preflight validation call PDType0Font.clear at the wrong time
> -------------------------------------------------------------
>
> Key: PDFBOX-3024
> URL: https://issues.apache.org/jira/browse/PDFBOX-3024
> Project: PDFBox
> Issue Type: Bug
> Components: Preflight
> Affects Versions: 1.8.10
> Reporter: Guillaume Monteils
> Attachments: 004973.pdf, PDF-Tools.png, PDFBox.png, eclipse-1.jpg, eclipse-2.jpg
>
>
> I used the algorythm here to test PDF / A compliance :
> https://pdfbox.apache.org/1.8/cookbook/pdfavalidation.html
> With one pdf document (which i cant give you due to confidentiality), an NullPointerException occur here :
> {code}
> java.lang.NullPointerException
> at org.apache.pdfbox.pdmodel.font.PDType0Font.getFontWidth(PDType0Font.java:188)
> at org.apache.pdfbox.preflight.font.container.FontContainer.checkGlyphWith(FontContainer.java:114)
> at org.apache.pdfbox.preflight.content.ContentStreamWrapper.validText(ContentStreamWrapper.java:372)...
> {code}
> As i dug deeper, i found that preflight loads a font context where it puts all pdf fonts. The PDType0Font is also created and put in this context.
> {code}
> (CSObject : COSDictionary{(COSName{BaseFont}:COSName{INWHIX+TimesNewRomanPSMT}) (COSName{DescendantFonts}:COSArray{[COSObject{349, 0}]}) (COSName{Encoding}:COSName{Identity-H}) (COSName{Subtype}:COSName{Type0}) (COSName{ToUnicode}:COSDictionary{(COSName{Filter}:COSName{FlateDecode}) (COSName{Length}:COSInt{260}) }) (COSName{Type}:COSName{Font}) })
> {code}
> The problem is that at the end of one step of the analysis, the clear method is called on the PDType0Font (see eclipse-1.jpg), but the font is still present in the context. On a second step, the same font is retrieved from the context, with no data in it, and the NullPointerException occurs (see eclipse-2.jpg).
> I tried the validation after removing the clear method from PDType0Font and it works just fine.
> I think the problem comes from this context, and a clear on a font should also trigger a deletion in this map.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org