Ulrich Telle

I am not sure if the wxPdfDocument version is the same in Codeblocks. The source exporter plugin of CodeBlocks uses version 1.0.2. The latest wxPdfDocument release is version 1.2.0. However, regarding this issue the versions don't make a noteworthy difference. I don't know whether CodeBlocks could update the included wxPdfDocument version easily, because the latest version requires wxWidgets version 3.2.x. However, I see traces of wxWidgets 3.2 support in the Code::Blocks source tree. So it should...

but I think it is not present in the new wxPdfDocument version. Can you please explain what is not present in the wxPdfDocument version? So it is invalid. What is invalid? The PDF for which you experienced a problem with the pasrer code? If yes, it would be of interest from which source the PDF originated.

Yes, it would be more defensive, I agree. However, this would be true for many PDF attribute accesses in the PDF parser code. For valid PDF files no crashes should occur. Only for broken PDF files crashes can be expected. Nevertheless I agree that even for broken PDF files a crash is not so nice. I will consider to update the parser code to avoid crashes (as it is done already for optional PDF attributes), even though they are unlikely to occur.

What is the problem? Did the application crash? If yes, provide a sample PDF document exposing the problem. At the point where "better check pointer stm" is asked for the pointer stm is already verified to be a pointer to an XRef stream and the attribute "Size" is a required attribute. If it doesn't exist, the PDF file is actually an invalid PDF file.

I replaced the MD5 code by a public domain version and replaced the file lena.jpg...

I will replace the lena.jpg by another image in course of fixing the MD5 issue.

I'm the creator and maintainer of wxPdfDocument and I'm definitely still active....

wxSQLite3 3.3.1 released