I understand that it is already incremented by push_back; that's not what I was trying to correct. The purpose of increasing m_nObjectCount there is to guarantee that the object numbers which will be added by Append are reserved for Append's use so that any other objects which are added concurrently (the object created for a stream's length) do not disrupt the continuous object numbers which Append is expecting. I'm not saying that my approach is the best way, but either there needs to be more complex logic for FixObjectReferences or the object numbers need to be reserved somehow.
- Mike Slegeir Ulrich Arnold wrote: > Hi Mike! > > I'm not sure, if your patch is correct. I think m_nObjectCount ist already > incremented via the call to push_back in line 24. > > Uli > > -----Ursprüngliche Nachricht----- > Von: Mike Slegeir [mailto:[email protected]] > Gesendet: Montag, 31. August 2009 23:27 > An: podofo-users > Betreff: Re: [Podofo-users] Unable to Append to a PdfStreamedDocument? > > I have come up with a (possibly hacky and short-sighted) solution to this > issue. I've only done limited testing, but it does seem to work for me. > There were actually two issues in appending to a > PdfStreamedDocument: > > 1. As I previously mentioned, the objects the PdfStreamedDocument uses for > the length of the object conflict (by having the same object number) as the > next in the source. > 2. m_vecObjects.GetSize() is not an accurate description of the number of > objects in a PdfStreamedDocument because streams are popped out of > m_vecObjects are they are completed. > > The patch that I've attached attempts to correct these issues by: > > 1. 'Reserving' object numbers in m_vecObjects before appending any objects > 2. Using m_vecObjects.GetObjectCount() - 1 for the difference (this may not > work in all cases; can someone verify?) > > Hopefully this will fix the issue, or at least inspire a better fix to make > it into the project. > > - Mike Slegeir > > Mike Slegeir wrote: > >> Sorry about the excessive replies, but I've figured out what's wrong, >> and I don't know how to fix it myself. What happens is when you copy >> a stream to the PdfStreamedDocument, it creates a new object for the >> length. Then the next object is copied (which has a conflicting >> object number with the just created length object). I think in order >> to handle this, some tweaking to FixObjectReferences may be necessary >> (since we've just created a new object which throws off references >> even more so) or the immediate writing of the stream length as the >> next object should be reconsidered. Any thoughts from someone more >> > familiar with this? > >> - Mike Slegeir >> >> Mike Slegeir wrote: >> >> >>> Alright, I've made a bit more progress on debugging this, but its >>> only gotten stranger. I believe the root cause is that a couple of >>> objects are being duplicated (9 and 11 I think in the document I >>> attached). The weird part is that it seems like the duplicates come >>> all the way from PdfDocument::Append which is strange because the >>> code there should be the same for both the PdfMemDocument and >>> PdfStreamedDocument. Yet the duplicate detecting code I added in >>> PdfVecObjects::push_back doesn't complain when I'm using a >>> PdfMemDocument to merge into. I'm really perplexed here and any insight >>> > will be helpful. > >>> - Mike Slegeir >>> >>> Mike Slegeir wrote: >>> >>> >>> >>>> I've narrowed this down a little. It looks like the problem is >>>> writing out the XRef and Trailer. The XRef overlaps itself at a few >>>> points (that's valid though, right?) and so the trailer's listed >>>> size comes from the last XRef subsection's first object and count >>>> (which is wrong because the last subsection was a short, overlapping >>>> subsection). I'm attaching a PDF generated from the >>>> PdfStreamedDocument merging. If someone with a better understanding >>>> could take a look at the XRef, I'd appreciate it. Thanks. >>>> >>>> - Mike Slegeir >>>> >>>> Mike Slegeir wrote: >>>> >>>> >>>> >>>> >>>>> I'm trying to use PdfStreamedDocument like so: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> PoDoFo::PdfStreamedDocument doc(out_filename); >>>>>> >>>>>> for(int i=0; i<num_inputs; ++i) { >>>>>> doc.Append( PoDoFo::PdfMemDocument(in_filenames[i]) ); >>>>>> } >>>>>> >>>>>> doc.Close(); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> but the result is just two blank pages. I'm currently doing >>>>> something like this: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> PoDoFo::PdfMemDocument doc; >>>>>> >>>>>> for(int i=0; i<num_inputs; ++i) { >>>>>> doc.Append( PoDoFo::PdfMemDocument(in_filenames[i]) ); >>>>>> } >>>>>> >>>>>> doc.Write(out_filename); >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> which works perfectly fine. Is anyone able to offer some insight >>>>> on why this doesn't work or any technical reasons that it >>>>> shouldn't? I'd like to be able to use PdfStreamedDocument for this >>>>> as merging lots of documents can take up a lot of memory seemingly >>>>> > unnecessarily. > >>>>> - Mike Slegeir >>>>> >>>>> ------------------------------------------------------------------- >>>>> ----------- Let Crystal Reports handle the reporting - Free Crystal >>>>> Reports 2008 30-Day trial. Simplify your report design, integration >>>>> and deployment - and focus on what you do best, core application >>>>> coding. Discover what's new with Crystal Reports now. >>>>> http://p.sf.net/sfu/bobj-july >>>>> _______________________________________________ >>>>> Podofo-users mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/podofo-users >>>>> >>>>> >>>>> >>>>> >>>>> >>> --------------------------------------------------------------------- >>> --------- Let Crystal Reports handle the reporting - Free Crystal >>> Reports 2008 30-Day trial. Simplify your report design, integration >>> and deployment - and focus on what you do best, core application >>> coding. Discover what's new with Crystal Reports now. >>> http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Podofo-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/podofo-users >>> >>> >>> >> ---------------------------------------------------------------------- >> -------- Let Crystal Reports handle the reporting - Free Crystal >> Reports 2008 30-Day trial. Simplify your report design, integration >> and deployment - and focus on what you do best, core application >> coding. Discover what's new with Crystal Reports now. >> http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Podofo-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/podofo-users >> >> > > > __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 4388 > (20090902) __________ > > E-Mail wurde geprüft mit ESET NOD32 Antivirus. > > http://www.eset.com > > > > __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 4388 > (20090902) __________ > > E-Mail wurde geprüft mit ESET NOD32 Antivirus. > > http://www.eset.com > > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
