|
OK - hopefully the unit test will help. Should I sit tight, or are there any pointers of where I should look? At this point, I'm not even entirely clear on which chunk of code is even responsible for writing the obj output to the pdf file... Maybe if I start with that I can back-track into PdfCopy and figure out where it's getting missed...
FYI - The current workaround of re-loading the reader is workable, just slow.
Thanks much,
- Kevin
----------------------- Original Message -----------------------
From: Paulo Soares <[EMAIL PROTECTED]>
To: Post all your questions about iText here <[email protected]>
Cc:
Date: Fri, 14 Nov 2008 17:21:24 +0000
Subject: Re: [iText-questions] Policy for adding unittests?
The problems you describe only happen in PdfCopy and not in PdfWriter or PdfStamper. That code (in PdfCopy) is fairly recent and barely tested. It will certainly have to be improved.
Paulo
From: Kevin Day [EMAIL PROTECTED] Sent: Friday, November 14, 2008 5:07 PM To: itext-questions-request@ Subject: Re: [iText-questions] Policy for adding unittests? Thanks for your comments. 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. So ideally, my test as written, should fail - for a single page stamp, we should only see a single XObject in the output (Xi0). What's interesting is that iText *does* generate a reference to Xi1 in the output - it just doesn't populate the actual object. So iText is not taking the optimal path (Which is fine with me, because the problem we are hitting is occuring regardless of whether we import the same page, or different pages). Here's more info:
In the test, you'll notice that we have two assertions when we are checking the XObject:
assertNotNull(indirectXObject); assertNotNull(directXObject); // <-- this is the one that is failing!! The indirectXObject does get retrieved from the stream - but it can not be de-referenced. I'm pretty sure this means that everything is being written to the output, except for the obj entry for the x object.
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.
So, in this particular situation - where the imported content is the same page over and over again, it would be perfectly legal (though inneficient) if iText created separate XObjects for multiple imports of the same page - but that's an optimization opportunity, not a bug. The bug, I think, is that when iText does generate separate XObjects from the same reader, it winds up leaving out the individual XObject obj output.
OK - so that's the simple case where the same content is being imported over and over again. This issue could be worked around by making iText more efficient (not generating multiple XObjects for imports of the same page) - but I don't think that would address the underlying problem that this test surfaces.
What's more troubling here, and what makes me think there is a bigger problem somewhere deeper in the library, is if you import *different* pages from the same reader, you get the same problem. In this case, you would expect to see a different XObject for each stream. And, indeed, you do see individual indirect XObject references - but the obj entries for those XObjects are not being written to the output.
I've just comitted a revised version of the unit test that shows the problem in both cases (where the same page is imported from the same reader multiple times, and when different pages are imported from the same reader).
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.
Thanks,
- K
----------------------- Original Message -----------------------
From: "Michael Klink" <[EMAIL PROTECTED]>
Cc:
Date: Fri, 14 Nov 2008 13:00:14 +0100
Subject: Re: [iText-questions] Policy for adding unittests?
Another way to fix this might be changing PdfCopy.getImportedPage. Here you can also try to remember all PdfReaderInstance instances. BTW, I'm not so sure anyway that closing the reader and readerFile here is such a good idea if re-use is intended. -----Original Message----- From: Michael Klink [mailto:[EMAIL PROTECTED] Sent: Friday, November 14, 2008 12:32 PM To: [email protected] Subject: Re: [iText-questions] Policy for adding unittests? 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, st ampPageNum++) 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 sa m e 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. -- Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD0 03K11308T4569a < BR>------------------------------------------------------------------------- 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
Aviso Legal: Esta mensagem é destinada exclusivamente ao destinatário. Pode conter informação confidencial ou legalmente protegida. A incorrecta transmissão desta mensagem não significa a perca de confidencialidade. Se esta mensagem for recebida por engano, por favor envie-a de volta para o remetente e apague-a do seu sistema de imediato. É proibido a qualquer pessoa que não o destinatário de usar, revelar ou distribuir qualquer parte desta mensagem. Disclaimer: This message is destined exclusively to the intended receiver. It may contain confidential or legally protected information. The incorrect transmission of this message does not mean the loss of its confidentiality. If this message is received by mistake, please send it back to the sender and delete it from your system immediately. It is forbidden to any person who is not the intended receiver to use, distribute or copy any part of this message. -------------------------------------------------------------------------
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 |
------------------------------------------------------------------------- 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
