Mailing-List: contact dev-help@pdfbox.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@pdfbox.apache.org
Date: Sun, 6 Dec 2015 17:12:11 +0000 (UTC)
From: "Tilman Hausherr (JIRA)" <jira@apache.org>
To: dev@pdfbox.apache.org
Message-ID: <JIRA.12904902.1444836240000.283252.1449421931016@Atlassian.JIRA>
In-Reply-To: <JIRA.12904902.1444836240000@Atlassian.JIRA>
References: <JIRA.12904902.1444836240000@Atlassian.JIRA>
 <JIRA.12904902.1444836240700@arcas>
Subject: [jira] [Commented] (PDFBOX-3024) Preflight validation call
 PDType0Font.clear at the wrong time
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/PDFBOX-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043951#comment-15043951 ] 

Tilman Hausherr commented on PDFBOX-3024:
-----------------------------------------

{code}
 (COSName{W}:COSArray{[COSInt{0}, COSArray{[COSInt{778}]}]}) }
{code}
This means that there is a width for CID 0.

My problem is that I'm just not really persuaded. Lets just wait until somebody else comes up with a file with the same problem.

> 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