Bugs item #1763550, was opened at 2007-07-30 14:29
Message generated for change (Comment added) made by domseichter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=790130&aid=1763550&group_id=154028
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: PdfDocument & PDF version 1.6
Initial Comment:
on: Mac OSX (10.4.9) using XCode (2.4.1)
PoDoFo (v0.5.0 - had to do some changes in order to build it on mac e.g.
removing mac-specific code regarding Carbon font APIs and removing files
(PdfParserBase & PdfRefCountedFile) and adding others instead - all this is not
related to images & documents i hope).
Bug: Trying to instantiate a PDFDocument using the constructor that gets a file
name (to be loaded into document) will crash.
This only happens with files of pdf version 1.6 (see attached sample to use as
input file) others are loaded successfuly and displayed as expected.
Error: indicates of ePdfError_InvalidDataType
this is thrown in line:
if( !m_pLinearization->GetDictionary().HasKey("Linearized") )
(in : PdfParser::ReadDocumentStructure() which is called when instansiating
PdfDocument with file attached (input.pdf)
when instantiating a PdfDocument, a PdfPardser is built, calling its member
ParseFile() which calls ReadDocumentStructure() which calls in turn to
HasLinearizationDict())).
I hope i havent missed anything.
Thanks in advance!
jonathan
----------------------------------------------------------------------
>Comment By: Dominik Seichter (domseichter)
Date: 2008-06-01 23:26
Message:
Logged In: YES
user_id=203039
Originator: NO
No update since July of last year and I cannot reproduce the bug with
current trunk and 0.6.0 branch. That's why I am going to close it. If this
bug is still present, feel free to reopen this issue.
Dom
----------------------------------------------------------------------
Comment By: Craig Ringer (ringerc)
Date: 2007-07-31 20:49
Message:
Logged In: YES
user_id=639504
Originator: NO
Please confirm if this fixes your issue so I can close this bug.
----------------------------------------------------------------------
Comment By: Craig Ringer (ringerc)
Date: 2007-07-30 15:23
Message:
Logged In: YES
user_id=639504
Originator: NO
Also, if you want to change this for 0.5.0 you must additionally delete
the `throw e;' in the catch block after the
if( !m_pLinearization->GetDictionary().HasKey("Linearized") ) { // blah }
block, so the code should read:
try {
static_cast<PdfParserObject*>(m_pLinearization)->ParseFile();
if (! (m_pLinearization->IsDictionary() &&
m_pLinearization->GetDictionary().HasKey( "Linearized" ) )
)
{
delete m_pLinearization;
m_pLinearization = NULL;
return;
}
} catch( PdfError & e ) {
PdfError::LogMessage( eLogSeverity_Warning, e.what() );
delete m_pLinearization;
m_pLinearization = NULL;
return;
}
----------------------------------------------------------------------
Comment By: Craig Ringer (ringerc)
Date: 2007-07-30 15:21
Message:
Logged In: YES
user_id=639504
Originator: NO
I can confirm the error you report with the sample PDF. I can not
reproduce it with other PDF 1.6 files, such as the PDF 1.6 reference from
Adobe. The exact error message is:
ePdfError_InvalidDataTypeError: An error 16 ocurred during uncompressing
the pdf file.
PoDoFo encounter an error. Error: 16 ePdfError_InvalidDataType
Callstack:
#0 Error Source:
/home/craig/build/podofo-clean/src/PdfVariant.h:679
By setting a breakpoint at the throw site, I can easily get a full
backtrace:
Breakpoint 1, PoDoFo::PdfVariant::GetDictionary_NoDL (this=0x80669a8)
at /home/craig/build/podofo-clean/src/PdfVariant.h:679
679 PODOFO_RAISE_ERROR( ePdfError_InvalidDataType );
(gdb) bt
#0 PoDoFo::PdfVariant::GetDictionary_NoDL (this=0x80669a8)
at /home/craig/build/podofo-clean/src/PdfVariant.h:679
#1 0xb7e63600 in PoDoFo::PdfVariant::GetDictionary (this=0x80669a8)
at /home/craig/build/podofo-clean/src/PdfVariant.h:669
#2 0xb7ebf75a in PoDoFo::PdfParser::HasLinearizationDict
(this=0xbfc06528)
at /home/craig/build/podofo-clean/src/PdfParser.cpp:275
#3 0xb7ebfc48 in PoDoFo::PdfParser::ReadDocumentStructure
(this=0xbfc06528)
at /home/craig/build/podofo-clean/src/PdfParser.cpp:136
#4 0xb7ec08aa in PoDoFo::PdfParser::ParseFile (this=0xbfc06528,
pszFilename=0x804e2ec "/home/craig/Desktop/input.pdf",
bLoadOnDemand=true)
at /home/craig/build/podofo-clean/src/PdfParser.cpp:107
#5 0xb7ec0c75 in PdfParser (this=0xbfc06528, pVecObjects=0x804e314,
pszFilename=0x804e2ec "/home/craig/Desktop/input.pdf",
bLoadOnDemand=true)
at /home/craig/build/podofo-clean/src/PdfParser.cpp:59
#6 0xb7e9f85e in PoDoFo::PdfMemDocument::Load (this=0x804e310,
pszFilename=0x804e2ec "/home/craig/Desktop/input.pdf")
at /home/craig/build/podofo-clean/src/PdfMemDocument.cpp:111
#7 0xb7e9fa7c in PdfMemDocument (this=0x804e310,
pszFilename=0x804e2ec "/home/craig/Desktop/input.pdf")
at /home/craig/build/podofo-clean/src/PdfMemDocument.cpp:63
#8 0x0804b348 in PdfInfo (this=0xbfc06644, [EMAIL PROTECTED])
at /home/craig/build/podofo-clean/tools/podofopdfinfo/pdfinfo.cpp:28
#9 0x0804b97c in main (argc=2, argv=0xbfc066f4)
at
/home/craig/build/podofo-clean/tools/podofopdfinfo/podofopdfinfo.cpp:51
Examining frame 0, we can see:
(gdb) frame 0
(gdb) print m_eDataType
$2 = PoDoFo::ePdfDataType_Array
.. that the linearization "Dictionary" is in fact an array, which is why
the GetDictionary() call at:
#2 0xb7ebf75a in PoDoFo::PdfParser::HasLinearizationDict
(this=0xbfc06528)
at /home/craig/build/podofo-clean/src/PdfParser.cpp:275
275 if( !m_pLinearization->GetDictionary().HasKey(
"Linearized" ) )
fails. Printing *m_pLinearization lets us determine the object number and
generation number (1 0 obj). Examining the PDF, we can confirm that the
first PDF object is in fact an array. Fine. This PDF has no linearization
dictionary.
So why the exception? PoDoFo wraps the check in a try/catch and should
ignore any exception thrown by treating the object as a linearization
dictionary when it's not. It's re-throwing the exception, however.
It looks like left over debug code, frankly. It should not be re-throwing,
but rather be logging the exception, cleaning up, and returning.
I've commited a fix in svn trunk. If you want to stick to 0.5.0 just make
the following change:
- if( !m_pLinearization->GetDictionary().HasKey("Linearized") )
+ if( !(m_pLinearization->IsDictionary() &&
m_pLinearization->GetDictionary().HasKey("Linearized")) )
in PdfParser::HasLinearizationDict().
Please update this bug to indicate whether or not this addresses your
problem.
On a side note, PoDoFo svn trunk has fixed Mac OS X support, and should
build out of the box. So that's an option for you. Using svn trunk the
xcode project is gone, but you can use CMake to generate an up to date and
correct one, or use unix makefiles - whatever you prefer. You will need to
change usage of PdfDocument to PdfMemDocument to use trunk, but should not
need any other changes.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=790130&aid=1763550&group_id=154028
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Podofo-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/podofo-users
