Memory leak when generating pdf

We’ve come across a memory leak with Aspose.Pdf

memory leak when using

   <Cell ID="original" Alignment="Center">
          <Text >
            <Segment Color="white" IsTrueTypeFontBold="true" >Original</Segment>

where value is :

<p class="MsoNormal" dir="RTL" style="margin-bottom: .0001pt; text-align: justify; line-height: 200%; text-justify: kashida; text-kashida: 10%; direction: rtl; unicode-bidi: embed;"><strong><span lang="AR-EG" style="font-size: 11.5pt;  font-family: 'Times New Roman',serif; mso-ascii-theme-font: major-bidi; mso-hansi-theme-font: major-bidi; mso-bidi-theme-font: major-bidi; mso-bidi-language: AR-EG;">فى منطقة أو دولة بعينها, وهو بعد جديد يضاعف من خطورتها, فنجدها فى الشرق الأوسط, وفى أفريقيا وفى أوروبا وأمريكا متجاوزة لكل الحدود والقوميات, بل وباتت تضم بين صفوفها أعضاء من مختلف الجنسيات الشرقية والغربية معا مما يؤكد استمرار قدرتها على التشعب والامتداد ومن ثم يفرض هذا التحدي دور ومسئولية أساسية علي المحليات في مكافحة التشدد والتطرف لدي الشباب .</span></strong></p>

After testing, we nailed down the issue to be the line-height: 200%


Please list down all steps to replicate the problem of memory leak. You might Zip source files and code, and then share by uploading in the forum post. We will investigate and share our findings with you.

Thank you for your reply.

Creating a sample is time-consuming so before I delve into this, I want to mention that we are still using Aspose.Pdf.Generator, not Aspose.Pdf DOM

I’ve already opened a ticket for an issue with Aspose.Pdf.Generator (Foreground colour triggers a carriage return - #4 by asad.ali) 6 months ago and to this day it is still not resolved although I provided a sample. The only answer I got was to update my code to the new version, which is not compatible with the old templates.

So can you confirm that if I provide a sample, you WILL fix the bug if there is one and you won’t ask me to use Aspose.Pdf.DOM as a workaround ? (247.9 KB)

Ok, I’m in a rush to get this fixed. Here’s the requested sample. Please get back to me asap.


Thanks for sharing a sample project and sorry for the delayed response.

We have tested the scenario in our environment and observed that the program consumed more than 1GB of system memory when line-height was set to 200%. Furthermore, the PDF generated with this value of line-height was also damaged, that it could not be opened in Adobe Reader.

We do understand that your existing routine follows the old XML structure and it will cost time, updating the existing code according to new DOM approach. But please note that old legacy approach has been obsoleted and discontinued in new version(s) of the Aspose.Pdf for .NET, as you already know that, and we are not providing support or resolving issues related to that approach.

Kindly also note that using Aspose.Pdf DOM is recommended as it contains more enhancements and improvements in terms of performance and memory usage. Which is why we always recommend our customers to use this approach along with latest version. We request you to please try converting your XML template according to DOM structure ( (1.6 KB)) and in case you experience any issue, please let us know. We will definitely test the scenario and forward the issue to product team after replicating it.


Adding more to my previous comments, as you are setting line-height as 200%, which means it will be twice of the font-size value. If the font-size is 11.5pt, the line-height will be 23pt (_200% of 11.5_). So if you set font-size as 11.5px and line-height as 23px (200% of 11.5px), the program will generate correct output. I have tested it on my side and for your reference, an output file is attached.

aspose.pdf (57.6 KB)

sure, but I don’t have control over that since it is user-generated content.

Looks like you are not going to fix the bug. Can you at least convert the sample to new code so we have an idea of how our new templates/code should look like?

Oh and by the way, we pay for an Aspose Total license, which is VERY expensive. Needless to say we are disappointed in your support. The new version should be backward compatible or you should at least offer a template converter, as we have tons of templates that we will need to refactor.

Trying to convert the sample myself, it is a real pain.

Why would I write

<Cell Alignment="3">

instead of

<Cell Alignment="Right">

  1. What is the reason behind this ??? It makes no sense to use enum value in a XML template. Did I miss something ? Because if I use “Right”, it triggers an exception.

Same thing for FontStyle=“1” instead of “Bold” …

  1. Also, it seems you have removed the ID attribute. How do I access the segment RequestIdentifier in the following XML in order to change the text from code ?

     <Table ColumnAdjustment="AutoFitToWindow" ColumnWidths="8 10">
           <DefaultCellPadding Top="0" Left="0" Right="0" Bottom="0" />
           <Margin Top="15" />
             <Cell Alignment="1">          
                 <TextSegment>0</TextSegment> <!-- request identifier -->
                 <TextState FontSize="14" FontStyle="1"></TextState>
  2. What is the new way to create tab ? ( #$TAB ) used to work but now it just displays that text.

  3. And by the way, the sample your provide does not work. Try XMLToPDF, in which you try to access an object “mainSection” :

Page page = (Page)doc.GetObjectById("mainSection");

This returns null because the provided log.xml does not look at all like the expected one…

  1. Please see attachment with pdf generated with old template and pdf generated with new template. See the header part is not correct (image size and alignement, text positioning, etc…) I’ve also attached my code. Can you show me how to get the exact same heading ? Also, the image path should not be hardcoded in the template, it should be set from code. But I couldn’t figure out how to do that. (63.5 KB)
new template.pdf (63.1 KB)
old template.pdf (61.5 KB)


We really apologize for all the inconvenience, you have faced. We have observed your concerns and are testing the scenario in our environment. We will definitely address all of the issues accordingly, as soon as we complete our testing. Please be patient, we will get back to you with results, shortly.


Thanks for your patience.

We have tested the scenario in our environment and observed the issues, which you have mentioned.

However, after adding the ID for Page tag, we were able to access it through code PageById.png (10.7 KB) but we were unable to access the text segment. We have logged following issue(s) and investigation ticket(s) in our issue tracking system. Our product team will further look into the details of the logged tickets and we will keep you informed with the status of their correction. Please be patient and spare us little time.

  • PDFNET-43742 (Alignment attribute in XML takes enum value instead of string)
  • PDFNET-43743 (Cannot access TextSegment with ID while generating PDF from XML)
  • PDFNET-43744 (Set image path from code while generating PDF from XML)
  • PDFNET-43745 (XML to PDF - Content is not overlapped and disordered in the output)
  • PDFNET-43125 (#$TAB is not working in new DOM based XML)

We are sorry for the inconvenience.

What can I say… On one hand you are asking me to be patient but we have an opened ticket that was created 6 months ago…
On the other hand you want us to upgrade to Aspose.PDF, but it does not have half the features of Aspose.PDF.Generator.

Currently we are stuck with a memory leak and a formatting issue you won’t fix. This is clearly not acceptable in regards to the premium we are paying.


Thanks for writing back.

Since we recommending our customers to use Aspose.Pdf (DOM) approach, so as soon as we observe any issue or missing feature in new DOM model, we report and log it in our issue tracking system, so that product team can look into the matter and work on providing the resolution or enhancement accordingly.

Please note that, product team has their own schedule of development and they resolve issue on first come first serve basis. I am afraid the earlier logged ticket is still open, due to large number of pending issues in the queue which were reported prior to that ticket.

Furthermore, we have recorded your concerns and intimated the respective team about them. As soon as we have some significant updates, regarding resolution of logged tickets, we will definitely let you know. We greatly appreciate your patience and cooperation in this matter. Please spare us little time.

We are sorry for the delay and inconvenience faced.

Where can I check the status and progress of these 5 tickets ?


Since these issues have been logged in our internal bug tracking system, so I am afraid that you cannot access them directly. However, we will keep you updated with the status and progress of these logged tickets, within this forum thread.

We are sorry for the inconvenience.


Thanks for your patience.

We are pleased to inform you that earlier reported issues PDFNET-43125 and PDFNET-43742, have been resolved in latest version Aspose.Pdf for .NET 17.12. Please try using the latest release version and in case you face any issue, please feel free to contact us.

let us know when the remaining 3 tickets are solved since we can’t use the new version without these fixes


We will surely let you know as soon as the remaining issues are resolved. We highly appreciate your patience and comprehension in this regard. Please spare us little time.

We are sorry for the inconvenience.


Thanks for your patience.

We are pleased to inform you that earlier logged investigation ticket PDFNET-43744 (Set image path from code while generating PDF from XML), has been resolved in Aspose.PDF for .NET 18.1. Please use attached 43744.xml with image id and following code:

string inXml = "43744.xml";
string inFile = "43744.png";
string outFile = "43744.pdf";
Document doc = new Document();
Image image = (Image)doc.GetObjectById("testImg");
image.File = inFile;
doc.Save(outFile); (683 Bytes)

Moreover, we will definitely keep you informed regarding remaining pending issues. Please be patient and spare us little time.

We are sorry for the inconvenience.