You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "John Hewson (JIRA)" <ji...@apache.org> on 2015/11/24 16:38:11 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=15024679#comment-15024679 ]
John Hewson edited comment on PDFBOX-3024 at 11/24/15 3:37 PM:
---------------------------------------------------------------
GID 0 is the "missing glyph". It is required to be present in every font but it only provides a fallback glyph (usually an empty rectangle) for use when the desired glyph is not present. This is equivalnet to the ".notdef" glyph in PostScript fonts. So yes, the glyph is present, but its presecnce indicates that the given character code isn't present in the font.
I suspect the problem is that preflight is checking that every glyph in the font is present in the Encoding embedded in the PDF and it's trying to check GID 0 too, but it should ignore that GID.
was (Author: jahewson):
GID 0 is the "missing glyph". It is required to be present in every font but it only provides a fallback glyph (usually an empty rectangle) for use when the desired glyph is not present. This is equivalnet to the ".notdef" glyph in PostScript fonts. So yes, the glyph is present, but its presecnce indicates that the given character code isn't present in the font.
> 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