Memory usage

What is the proper way to handle memory usage with DynamicPDF Merger? 

I'm extracting pages from 2 PDFs, placing them in the correct order, and adding backgrounds to each page.  The total number of resulting pages could be several hundred.  I'm using ImportedPageData to create a memory image of the 4 different backgrounds once at the beginning of the processing so that I don't have to read it each time. 

As I merge pages, my memory usage grows until I exceed all I have (4GB on a Vista 32bit system) after about 150 pages.

Could you suggest and provide examples of the recommended ways to manage memory as you build a merged PDF?

Thanks,

So, I think I get everything you are saying and my suggestions below will be based on that assumption.  If this was not a correct interpretation of your requirements then be sure to clarify and expand.  It sounds like you will be taking certain pages from certain existing PDF documents and using those pages (in no particular order) as backgrounds for a resulting PDF document. 

To accomplish something like this you would just want to first create a PdfDocument out of each PDF that you will be reusing.  You will always want to use a PdfDocument when reusing a PDF (it is much more efficient that way).  After that then you can just Append (using the PdfDocument that you want) the particular page you want to use (specifying the particular start page and total number of pages, in your case 1).  Appends can continue in any order until the Document is completed.

I am putting some very simple code below that demonstrates this concept.  Obviously you will just need to expand upon this to accomplish your exact needs:

            PdfDocument pdf1 = new PdfDocument("C:\\doc1.pdf");
            PdfDocument pdf2 = new PdfDocument("C:\\doc2.pdf");
             
            MergeDocument document = new MergeDocument();

            // Append page 2 of document 2
            document.Append(pdf2, 2, 1);

            // Append page 1 of document 2
            document.Append(pdf2, 1, 1);
           
            // Append page 2 of document 1
            document.Append(pdf1, 2, 1);

            // Append page 1 of document 1
            document.Append(pdf1, 1, 1);

            //You can continue to Append pages as you need to for any template you want to use

            document.Draw("C:\\output.pdf");

Give this type of logic a try and please let us know if that improves the overall efficiency of how you application is running.  Let us know if you need any clarification.

Thanks,
ceTe Software Support Team

I like your solution.  I'm not sure if I can use it.

Here's what I'm doing.

Dim nCurrentPage as Long
Dim nPageCount as Long
Dim flgUseBackground as Boolean
Dim pdfInsertPage as Page
Dim pdfDocument As MergeDocument = New MergeDocument
Dim fileStatementVarData as String

'nPageCount, fileStatementVarData, etc. are read from a database

For nCurrentPage = 0 To nPageCount-1
    if flgUseBackground Then
        pdfInsertPage = Nothing
        pdfInsertPage = New Page
        pdfDocument.Pages.Add(pdfInsertPage)
        pdfInsertPage.Elements.Add(pagdataStatementBackground)

        Dim MyVariableData As ImportedPageData = _
            New ImportedPageData(fileStatementVarData, _
            nCurrentPage + vardataStartPage)
        pdfInsertPage.Elements.Add(MyVariableData)
        MyVariableData = Nothing
     End If
Next nCurrentPage

I hope that illustrates it.  The reason I'm using Elements.Add rather than Append is that I could get the background underneath the variable data that way by applying the background first.  Can I use Append for the variable data page and then add elements at the back?  I didn't find a "z-order" or similar property that would let me place one element behind another.

Thanks,

Rick

Hello Rick,

There is no z-order property to add elements to the page. The elements will be added in the order how you are adding the elements to the page. The last added element will be added on the top.

You can use Append method only when adding pages or documents to an existing PDF document. You can not use this method to add page elements.

You can also use the document templates to add elements as background. You can also use the TransperencyGroup to set some transperancy for the elements. You can refer to the Templates on our help documentation.

Thanks,
ceTe Software Support Team.

Will templates use memory more effectively?  With the current method I'm using, which appears to be my only option without restructuring my whole approach, I'm basically limited to assembling about 150 pages using page by page backgrounds.  Then the document assembly crashes the application due to exhausting all memory.  The output file is about 3MB at that point, so consuming 2GB or so of RAM during processing seems excessive.

Thanks.

Hello Rick,

Yes, using the templates will be efficient. Our product is created keeping the efficiency in mind. We are able to generate PDF file of size 300MB without any problem. Please make sure that you are using the objects you created in a proper way. Double check your code if any objects are causing this problem.

What exactly you wanted to achieve? Please send the details about  how you are using our product and what you wanted to achieve to our Support Team so that they can look into it further to suggest an efficient way of doing it.

Thanks,
ceTe Software Support Team.

Here's my task.

Output:
A single PDF containing a series of customer documents consisting of pages from PDF 1 followed by pages from PDF 2, with appropriate backgrounds applied to the pages of PDF 1, and different backgrounds for the pages of PDF 2.

Input:
1) 2 PDF's (PDF 1 and PDF 2) prepared with variable data for a list of customers.
2) An index that tells me where each customer's pages start and how many pages the customer has in each of the PDFs
4) A set of static background PDFs that get applied to the customer pages.  In my current project, there are 4 static background PDFs that correspond to the odd pages of PDF 1, the even pages of PDF 1, the odd pages of PDF 2, and the even pages of PDF 2.

Current method:
1) Open a PDF document
2) Begin looking at the index of customers
3) For each customer, add a page from PDF 1, apply the appropriate background, and repeat until done with the pages for this customer for PDF 1.  (In the case of my current data, I add an odd page from PDF 1, apply the background, add an even page from PDF 1, apply the background, and repeat until done with the pages for this customer for PDF 1.)
4) Repeat #3 for PDF 2
5) Repeat #3 and #4 for all the customers
6) Draw the PDF document

The reason I didn't use the even/odd template is because not all the projects to be handled by this software fit that model.  Since the even/odd template has to be applied to the whole document, I can rearrange my software for my first project to use the even/odd template to apply the backgrounds first, then assemble the two PDFs.  The above sequence is more general, though, and I may not always have even/odd pages to work with.  Any suggestions that would manage memory correctly while assembling arbitrary arrangements of pages with backgrounds would be appreciated.

Thanks,

Rick

Hello Rick,

Other option is by using Sections. You can use sections and apply templates to specific sections. You can refer to the Document Sectioning topic in the Help Documentation that shows using templates within sections.

Thanks,
ceTe Software Support Team

Aha, that sounds very useful!  Is there any limit to the number of sections in a document?

Thanks.

I tried it.  Using templates and sections made no apparent difference to the memory problem.  After the program assembled about 60-70 sets of pages (total of perhaps 400 pages), memory usage was at 90%+ of my 4GB of RAM.  It hung in there between 93%-97% for awhile (using virtual memory, I assume), then crashed at about the 110th set of pages.

I can probably work around this by breaking the project down into many documents containing sets of 50 or so, then combining those afterwards.  I'm still hopeful there is an option to use your libraries differently or properly where the libraries optimize memory usage somehow during document assembly.

Thanks,

Rick

Hello Rick,

We are able to run a similar program which adds a background for each page of a document and we are merging around 150 PDFs to make a final PDF. We have not encountered any memory issues with our code. We have generated a 7MB output PDF file in this scenario. Please send a email to our Support Team so that we can give you the sample code we are using.

Thanks,
ceTe Software Support Team.