|
Original contributor was Mark Thompson (http://1t3xt.com/about/acknowledgments/index.php?page=people&id=60) - the original release did not update the currentPdfReaderInstance value in getImportedPage() (although it did override the method), so I don't think we will get info from that avenue. The second commit after that (3/6/03) has the change in it.
The SVN comments don't reference a change request or bug, so my ability to research it stops at that point.
Maybe Paulo will have a little bit of time after Christmas and we can pick it up from there. PdfCopy is somewhat of the ultimate solution here - it can append pages, add stamps, encrypt, etc... things that you just can't do in a single step with any of the other classes in iText, so it would be great to get this working. As I've said before, the current workaround is livable.
Paulo - if there is anything I can do to help, please let me know.
- K
----------------------- Original Message -----------------------
From: Paulo Soares <[EMAIL PROTECTED]>
To: Post all your questions about iText here <[email protected]>
Cc:
Date: Mon, 17 Nov 2008 11:31:37 +0000
Subject: Re: [iText-questions] Policy for adding unittests?
PdfCopy was a contribution and I did some changes to it. Unfortunately I don't have the time to look at what I did for the time being, at least not until Christmas.
Paulo ________________________________________ From: Michael Klink [EMAIL PROTECTED] Sent: Monday, November 17, 2008 8:48 AM To: [email protected] Subject: Re: [iText-questions] Policy for adding unittests? Kevin, if the persons who introduced both the PdfWriter.currentPdfReaderInstance member and the PdfCopy.getImportedPage(PdfReader, int) override are still available, it might be best if they could provide some input on * what the currentPdfReaderInstance is intended to be used for and * why PdfCopy overrides getImportedPage (and other methods) changing the use of that variable.< BR> This input should be added as comments and unit tests to the code and then be a base for further action concerning your unit test. Second guessing first seems to me a waste of time. When I read the iText book and look at the examples, PdfCopy.getImportedPage is only used in immediate concert with PdfCopy.addPage applied to the imported content; even when stamping is used (e.g. ConcatenateWithTOC), the imported page is stamped on and then addPaged, not used as stamp. This is along the lines of your theory. This seems to imply that other use is improper use here, in this case your unit test. If this is the case, PdfCopy should enforce this. Maybe changing the architecture itself would be appropriate, like creating a wrapper as with PdfStamper/PdfStamperImp, maybe some minor change would suffice. First, though, some documentation should be added. Obviously the use case you have in mind (using an imported page as stamp) also is an interesting one, but maybe it should be implemented using first some PdfCopy action and afterwards a PdfStamper doing the stamping. Regards, Michael. -------------------------------------------------------------------------------- From: Kevin Day [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2008 3:17 AM To: IText Questions Subject: Re: [iText-questions] Policy for adding unittests? Good point. I've updated the unit test to check for page 1 content as well. As you suggested, I overrode PDFCopy.getImportedPage() so it just delegates to super - that does indeed fix the problem that the unit test displays (all content streams are present and accounted for). I think that we need to understand what PDFCopy is doing with currentPdfReaderInstance - here is my theory: The *primary* purpose of getImportedPage() (in terms of how PdfCopy was or iginally designed, anyway) is to grab the imported page for the *primary* content of the PdfCopy (i.e. the source PDF - *not* the stamp PDF). The reason there is special handling for getImportedPage is that as the primary input PdfReader changes, the state of PdfCopy has to change (does it????). Now, we come along and try to use getImportedPage() to obtain content for a stamp, and that method just isn't intended for that (or maybe a better way of saying it is that the semantics of getImportedPage() in PdfCopy are inconsistent with the semantics of the method in PdfWriter). So, it seems to me that there are three potential approaches here: 1. Move the logic for changing the currentPdfReaderInstance into PdfCopy.addPage() (I'm not sure if doing so will impact PdfCopy.PageStamp.alterContents() ) - interestingly, addPage() *already* changes the currentPdfReaderInstance value, so I'm pretty sure the only functionality that would need to b e moved is the logic for closing the file of the old instance. or 2. add a special getImportedPage() call to the PdfCopy.PageStamp class or 3. make absolutely certain that changing the currentPdfReaderInstance in PdfCopy is actually necessary - if not, remove it. Note that when I return getImportedPage() so it just delegates to super, the output files of my simple tests work fine. But these all have the same page size, rotation, etc... - I'm not sure exactly what state in the currentPdfReaderInstance that PdfWriter is dependant on, so I can't say the implications of undoing this method override. Thoughts or comments? - K 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 en vie-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 an ywhere 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
