The problem with PdfCopy is that there are a lot of PdfReaderInstance around,
both from the pages and from the import when adding content. It was really a
hack to be able to import pages. I don't have any pointers for the time being.
Paulo
________________________________
From: Kevin Day [EMAIL PROTECTED]
Sent: Friday, November 14, 2008 5:29 PM
To: itext-questions-request@
Subject: Re: [iText-questions] Policy for adding unittests?
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]><mailto:[EMAIL PROTECTED]>
To: Post all your questions about iText here
<[email protected]><mailto:[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]><mailto:[EMAIL PROTECTED]>
To:
[email protected]<mailto:[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]<mailto:[EMAIL PROTECTED]>
Sent: Friday, November 14, 2008 12:32 PM
To:
[email protected]<mailto:[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/)<http://jpdfunit.sourceforge.net/> would make
writing tests easier.
Best regards, Michael.
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
