Kevin, your fix indeed makes sure that the second XObject is included in the PDF... unfortunately the first one is not in there anymore. Therefore "testXObject(true, 2, "Xi1")" doesn't fail while a test for Xi0 on page 1 would fail.
As written before the problem is that PdfWriter.importPages only contains one PdfReaderInstance object per PdfReader while your usecase creates multiple such instances for the stampReader all of which are required during PdfWriter.close for a complete document. Your fix only changed the Reader kept... 2.1.4 only kept the instance created first while your fix only keeps the instance created last. A possible fix: If you simply delete the method PdfCopy (and thus don't override PdfWriter.getImportedPage anymore) the existing PdfReaderInstance object is reused, so only one XObject is created referenced indirectly as "2 0 R", on the first page named /Xi0, on the second named /Xi1. I simply don't know whether the override which creates separate PdfReaderInstance objects fairly often, had been done for some reason that is still valid. Regards, Michael. -----Ursprüngliche Nachricht----- Von: Kevin Day [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 15. November 2008 02:23 An: [email protected] Betreff: Re: [iText-questions] Policy for adding unittests? Excellent information from everyone - thank you. I did a little digging - and I think I have a fix - but I wanted to make sure my fix doesn't have any unexpected consequences before I submit it. The fix is to add two lines (indicated in comments below) to PdfCopy.getImportedPage() : public PdfImportedPage getImportedPage(PdfReader reader, int pageNumber) { if (currentPdfReaderInstance != null) { if (currentPdfReaderInstance.getReader() != reader) { try { currentPdfReaderInstance.getReader().close(); currentPdfReaderInstance.getReaderFile().close(); } catch (IOException ioe) { // empty on purpose } currentPdfReaderInstance = reader.getPdfReaderInstance(this); importedPages.put(reader, currentPdfReaderInstance); // add this to fix issue +++++++++++++++ } } else { currentPdfReaderInstance = reader.getPdfReaderInstance(this); importedPages.put(reader, currentPdfReaderInstance); // add this to fix issue ++++++++++++++++ } return currentPdfReaderInstance.getImportedPage(pageNumber); } Once I make those changes, the unit tests pass, and the XObjects actually get written as they should. Now - is there anything about what I'm doing here that is bad/wrong? Also, it would be nice to get a quick explanation of why PdfCopy requires a special implementation of getImportedPage that changes the currentPdfReaderInstance whenever pages are being imported. Thanks all, - K ----------------------- Original Message ----------------------- From: "Michael Klink" <[EMAIL PROTECTED]> To: [email protected] Cc: Date: Sat, 15 Nov 2008 00:10:29 +0100 Subject: Re: [iText-questions] Policy for adding unittests? Kevin, Paulo, > If I can paraphrase a bit: if we are re-using the same stamp page, > it would be more optimal if iText generated a single XObject for it > and re-use the XObject on each page. That would be ideal. But as mentioned (and as you saw yourself) even stamping from different pages of the same source file fails if you imported from some other file inbetween. The reason are the multiple PdfReaderInstance instances generated in that case while only the one of them generated first is stored in PdfWriter.importedPages. > If you open the PDF generated immediately following the failed test > (if you are on Windows, you can uncomment the openFile(out) line > in testWithoutReloadingStampReader() ), you'll see that Adobe also > chokes on the missing Xi1 reference. Yes, obviously, as the second XObject is not included in the document (due to the reason mentioned above), but an indirect reference has been created --> Acrobat chokes. > Can anyone point me in a direction to determine when in the > PdfContentByte.addTemplate() call the object content for the > imported page actually gets added to the writer? The indirect > reference is certainly being added - but the actual object content > (i.e. the 10 0 obj ..... stuff) is never making it into the output stream. It is NOT added to the writer during addTemplate. In that method a PdfReaderInstance for that reader is marked for the page in question and is offered to the PdfWriter to add it to its importedPages Map. This only happens, though, if there is not yet an instance for that very reader added. During PdfWriter.close() PdfWriter.addSharedObjectsToBody() is called and adds the pages marked in the importedPages PdfReaderInstance instances to the result document --- and, therefore, any pages marked for import in some PdfReaderInstance that has been rejected from being added to importedPages are NOT added to the result document. I wonder why there is an override for the PdfWriter.getImportedPage method in PdfCopy. The PdfWriter version looks as though it would work alright for PdfCopy, too. I have not yet used PdfCopy very much, so maybe there is some reason... Regards, Michael. -- 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
