pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (PDFBOX-337) Patch for two bugs: 1 in PDDocument.load 1 in PDFMergerUtili
Date Mon, 04 Aug 2008 17:42:46 GMT

     [ https://issues.apache.org/jira/browse/PDFBOX-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jukka Zitting resolved PDFBOX-337.

    Resolution: Fixed

[Comment on SourceForge]
Date: 2008-05-21 18:48
Sender: danielwilson
Logged In: YES 
Originator: NO

Thanks, Brian.  

I'm always in favor of improved error trapping!

> Patch for two bugs: 1 in PDDocument.load 1 in PDFMergerUtili
> ------------------------------------------------------------
>                 Key: PDFBOX-337
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-337
>             Project: PDFBox
>          Issue Type: Bug
>          Components: Parsing
> [imported from SourceForge]
> http://sourceforge.net/tracker/index.php?group_id=78314&atid=552832&aid=1889131
> Originally submitted by bwingenroth on 2008-02-07 14:27.
> I've come across two bugs that the attached patch addresses.  I don't claim to fully
understand these bugs, nor do I know whether my patch fixes the root issues -- I only know
that using this patch allows me to continue using PDFBox.
> I came across a ClassCastException in PDDocument.load.  It actually manifests as an IOWrapperException
caused by the ClassCastException.  In getObjectsByType inside the file COSDocument.java, you
grab the COSdictionary and attempt to cast each item as a COSName.  I've found a PDF that
opens fine in Acrobat that apparently contains a COSObject inside that dictionary which throws
the ClassCastException.  My patch for COSDocument.java wraps the cast in a try block and silently
discards the ClassCastException.  This looks like it's safe, since the code seems to want
to match a COSName against a type passed into the function.  If the item isn't castable as
a COSName, then I assume it could never pass anyway, so my patch ignores it.
> The second issue -- in PDFMergerUtility.java -- is that srcNums can be null.  
> COSArray srcNums = (COSArray)srcLabels.getDictionaryObject( COSName.getPDFName( "Nums"
) );
> My patch tests srcNums to make sure it isn't null before iterating over it.
> Again, I don't know that I've addressed the underlying causes behind these issues, but
I have successfully patched the nightly build from 20080205 with these changes and haven't
noticed any ill effects.
> [attachment on SourceForge]
> http://sourceforge.net/tracker/download.php?group_id=78314&atid=552832&aid=1889131&file_id=265468
> PDFBox-0.7.4-dev-20080205.patch (application/octet-stream), 2757 bytes
> Patch for bugs in PDDocument.load and PDFMergerUtility

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message