________________________________
> Date: Sun, 25 Apr 2010 10:58:06 -0700
> From: ke...@trumpetinc.com
> To: itext-questions@lists.sourceforge.net
> Subject: [iText-questions] Performance when flattening form fields
>
>
>
>
>
>
>
>
>
>
> I've been doing some digging into the performance question that Giovanni Azua
> has posted about.
>
>
>
> Some of his findings (using StringBuilder, etc...) are solid improvements to
> overall iText performance - however, the crux of the performance difference
> he is seeing between iText and the competing solution is not low level. It's
> a high level issue.
>
>
>
> Here's what's going on:
>
>
>
> His specific use case involves stamping headers and footers onto pages. The
> footer contains AcroFields that must be flattened prior to stamping.
>
>
>
> The performance hit is coming from the fact that, in order to flatten and
> apply the footer, he is having to:
>
>
>
> 1. Construct a PDF using PdfStamper
>
> 2. Write output to a byte array output stream
>
> 3. Re-parse the BAOS into a PdfReader
>
> 4. Import the page from the reader for use as a stamp
>
>
>
> While this is functional, it is certainly not performant.
>
>
>
> A much, much faster technique would be to do the flattening to the *reader*,
> then just import the page to the output writer. This avoids the awkward
> creation of the temporary PdfReader.
So, there is no internal representation of a pdf doc you can pass around
without converting to a file format? If I understand you, you are
saying that he is forced to convert a bunch of structures into
a pdf file just so he can re-parse this file back into an
internal set of structures for further work?
How do you know the other package doesn't have to do this?
Is this only an issue with flattenning or is that just the specific
problem here but other operations may encounter simmilar problems?
>
>
>
>
>
> So, the performance delta is not caused so much by iText's low level
> implementation (although the performance improvements that Giovanni has
> suggested will help to make iText even faster than it already is) - the delta
> is really caused by an awkward operation forced on the user by the framework.
>
>
>
>
>
> So, are there any fundamental reasons to not do flattening, etc... to the
> PdfReader? My first look at the code indicates that it may be possible to
> factor this out of PdfStamper (basically, instead of adjusting the AcroFields
> dictionary and content streams in the PdfStamper/PdfCopy/etc... output, we'd
> make those adjustments to the PdfReader).
>
>
>
> I'm thinking of something along the lines of:
>
>
>
> PdfFormFlattener(PdfReader).flatten(pageNumber)
>
>
>
> Maybe with supplemental methods for flattenNamedFields(pageNumber),
> flattenFieldsOfType(pageNumber)
>
>
>
> Thoughts?
>
>
>
> - K
>
>
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
------------------------------------------------------------------------------
_______________________________________________
iText-questions mailing list
iText-questions@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/itext-questions
Buy the iText book: http://www.itextpdf.com/book/
Check the site with examples before you ask questions:
http://www.1t3xt.info/examples/
You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
