Kevin, I think the problem is due to PdfCopy.getImportedPage requesting a new PdfReaderInstance from the PdfReader (because of switching from reader to reader in your test case) and PdfReader.getPdfReaderInstance generating and returning a new instance each time. This makes PdfCopy.getImportedPage(stampReader, stampPageNum++) import the one stamp page time and time again giving it different indirect references.
PdfWriter.addDirectTemplateSimple() on the other hand only adds PdfReaderInstance instances to importedPages if there is not yet a PdfReaderInstance for the same reader already there. PdfWriter.addSharedObjectsToBody eventually tries to serialize the imported pages and finds only the first PdfReaderInstance in importedPages, thus only serializes the first XObject. So, when adding page 1 from pageReader a second time, the new PdfReaderInstance generates the XObject a second time with a different indirect reference which is referenced in the second result page. As this PdfReaderInstance is not added to PdfWriter.importedPages, though, the second XObject is not serialized into the document. This might be fixed by making PdfReader.getPdfReaderInstance(PdfWriter writer) remember the instances returned and return the same instance when called for the same writer. Obviously it should remember them only as long as there still is a (Java object) reference pointing to the instance in question, otherwise this could be quite a memory leak. -> WeakReferenceMap variants. Alternatively PdfWriter.addDirectTemplateSimple may not reject multiple PdfReaderInstances for the same PdfReader, at least keeping the duplicates for serialization by PdfWriter.addSharedObjectsToBody. This unfortunately allows for unnecessarily repeated PDF objects. Hope this helps. Xavier, maybe JpdfUnit (http://jpdfunit.sourceforge.net/) would make writing tests easier. Best regards, Michael. -------------------------------------------------------------------------------- From: Kevin Day [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2008 1:06 AM To: [EMAIL PROTECTED] Subject: Re: [iText-questions] [Itext-developers] Policy for adding unittests? The issue doesn't have to do with parsing content (I wish!), but I was able to write a fully encapsulated unit test for the problem - hopefully this will help track down the root issue. I have submitted the unit test: test/core/com.lowagie.text.pdf.TestPdfCopyAndStamp Would someone be willing to give it a run and see if they can spot the problem? Core issue is described here: http://www.mail-archive.com/[email protected]/msg40950.html I'm not sure if this issue would be considered to be exotic or not - it seems like a pretty common use case. Again, I wish I could bring a solution to the table, and not just a problem... Thanks, - K ----------------------- Original Message ----------------------- From: Xavier Le Vourch <[EMAIL PROTECTED]> To: iText Developers <[EMAIL PROTECTED]> Cc: Date: Thu, 13 Nov 2008 12:14:51 -0800 Subject: Re: [Itext-developers] Policy for adding unit tests? Kevin Day wrote: > I have a unit test that shows a problem with PdfCopy (it leaves off xobject > content streams in certain situations). > > Some OS projects I work on don't want unit tests uploaded unless there is a > fix available, > others prefer to have the unit test so they know they have a problem. > > Unfortunately, my digging so far has not brought me to a point where I'm able > to determine > root cause or suggest a fix. > > What is the iText policy, and should I commit the test? I don't think there's a policy in place as unit testing is a pretty recent addition and it's not that easy to test the generated pdf files. Testing the parsing of pdf should be easier to automate though... FYI, in the PMD project, I've added a flag to some tests and we have two ant targets, "test" and "regress". "regress" tests should not fail and if they do, the build fails and the hudson CI serv er will notify the developers. "test" on the other hand contains all the "regress" tests plus some exotic cases that are not solved yet and do not block a new release. I believe it's better to have them there than commented out as it used to be. I could implement the same framework for iText, with maybe making "test" be the regression test and creating a new target for the extra tests that may fail but will not prevent a new release. Xavier -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.1t3xt.com/docs/book.php
