[
https://issues.apache.org/jira/browse/PDFBOX-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14959227#comment-14959227
]
Tilman Hausherr commented on PDFBOX-3024:
-----------------------------------------
Things are not that easy, sadly. Your suggestion for 2.0 makes the rendering of
PDFBOX-2939 fail with an IOOBE.
I was able to find a file (004973.pdf, it is not PDF/A) with the same exception
in 1.8 and the same error in 2.0. But is it an error? [PDF-Tools
validation|http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx] mentions
"The width for character 0 in font 'Symbol' does not match." If allowed, try
checking your file there.
I'm not planning to do work on this for 1.8 as it is likely also complicated.
Removing the clear() at that place could result in memory leaks. I rather
suspect a different problem, e.g. incorrect assignment of resources.
The 2.0 version of preflight is much better (passes most Bavaria tests) and
will be released soon.
> 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, 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: [email protected]
For additional commands, e-mail: [email protected]
