Good morning,

sorry for my beginner's mistakes, but working with SVN and programming in C++ 
is quite new formm e.

You are absolutely right. The subject should be "bug in PdfDocument".

As I found out yesterday afternoon, my suggested fix does not solve all of the 
problem. On the one hand the document looks fine on the first view. On the 
other side, some strange behaviors occurred. This has to do with a signature I 
added to the document. After the pdf generation the signature looks fine. After 
filling some form fields, the signature is marked as "not valid". And on top I 
cannot save the document after validating a second blank signature field.

I had a closer look to the document and tried to find out where the problem 
could be by reading the Adobe's PDF specification, but I could not find out, 
where the problem ist.

Perhaps somebody else has an idea, how to fix the problem. When I have a final 
solution, I will try to provide a fix with SVN. If you want to, I could provide 
the complete PDF-file if it's helpful.


Best regards.

Hendrik
-----Ursprüngliche Nachricht-----
Von: zyx [mailto:z...@litepdf.cz] 
Gesendet: Mittwoch, 30. November 2016 11:37
An: podofo-users@lists.sourceforge.net
Betreff: Re: [Podofo-users] Bug in PdfVecObjects

On Wed, 2016-11-30 at 08:41 +0000, Dependahl, Hendrik wrote:
> I found an error in the call “PdfVecObject”
> affecting the use of PdfStreamed documents in combination with 
> XObjects.
> 
> ...
>  
> Inside the PdfVecObjects-the call must look like:
>  
> unsigned int difference = static_cast<unsigned
> int>(m_vecObjects.GetObjectCount())                             //__
> CORRECT
> ...

        Hi,
thanks for reporting the problem.

Particularly, you say that the bug is in PdfVecObjects, but your proposed 
changes do not touch it. Also, it would be more convenient to provide patches, 
then you'll not need to hardly describe the place where your changes should be 
done and it also avoids other confusion.
Either you can generate them from a svn checkout, or use command like:

   $ diff -upr PoDoFo.orig/ PoDoFo.changed/ >podofo.patch

Then _attach_ the proposed patch to an email and send it to the list, ideally 
keep threading (reply to this message).

Looking at the PdfDocument::Append(....), it looks like there is some idea 
behind the current behaviour (I do not say it's correct), because a comment 
right below the line you want to change says:

    // Ulrich Arnold 30.7.2009: Because GetNextObject uses m_nObjectCount 
instead
    // of m_vecObjects.GetSize()+m_vecObjects.GetFreeObjects().size()+1
    // make sure the free objects are already present before appending to
    // prevent overlapping obj-numbers

from which I understand that your change also makes those following lines 
useless. It needs some testing, though.
        Bye,
        zyx

-- 
http://www.litePDF.cz                                 i...@litepdf.cz

------------------------------------------------------------------------------
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users
------------------------------------------------------------------------------
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Reply via email to