We are doing an eval on Aspose products and were on the verge of looking at purchase, however I found a potential gamebreaker last week. Hopefully there is a way around this.
I was testing the conversion of a 7MB spreadsheet(.xls) to PDF and found that when doing the save, it was performing rather bad, ended up consuming around 2GB of RAM before it was all done, and resulted in a 14MB PDF.
In addition to that, I was turning around and attaching that PDF to another PDF, which resulted in a 122MB PDF.
A few snippets below.
Converting the spreadsheet to PDF(results in a 14MB PDF, consumes 2GB RAM):
var workbook = newWorkbook(Source); workbook.Save(Destination, FileFormatType.Pdf);
Attaching the PDF to another PDF(results in a 122MB PDF):
var editor = new Kit.PdfFileEditor(); editor.Concatenate(input_streams.ToArray(), io_stream);
* where input_streams is a list of FileStream's, that also contains io_stream. In this case, there were only 2 PDF's(335KB, 14MB from previous snippet)
Attaching the PDF to another PDF(results in a 122MB PDF):
var editor = new Kit.PdfFileEditor(); editor.Concatenate(input_streams.ToArray(), io_stream);
* where input_streams is a list of FileStream's, that also contains io_stream. In this case, there were only 2 PDF's(335KB, 14MB from previous snippet)
Hi Levi,
I'm a representative of Aspose.Pdf.Kit team and I would be helping you in your issue with the Concatenate method. Could you please share the two input PDF files you're trying to concatenate? We'll investigate the issue at our end and update you accordingly.
Thanks all for the replies. I apologize it took a little longer to get back with the attachments, but we had to 'obfuscate' some data and then I had to retest to validate it was still an issue on the 'cleansed' scenario.
Below are the versions for the dll's that I currently have referenced(all are for the .NET framework):
Aspose.Cells.dll - 5.2.0
Aspose.Pdf.Kit.dll - 5.1.0 (don't ask me how I got 5.1.0 here, but 5.2.0 on cells)
I'm attaching a zip file that contains the original pdf, the spreadsheet, as well as the spreadsheet converted to pdf(for use in testing the concatenate with the original).
Also of note, I thought that perhaps using a single stream to the original pdf as an input stream AND output stream could have been causing the larger size for the concat, so I retested using a separate output stream, to a new file. I've verified that doing that also produces a pdf of significant size(with the cleansed spreadsheet and resulting pdf, it is now ~300MB for the concatenated pdf). I left off the 300MB resulting pdf, for obvious reasons, but can provide it if necessary.
Initially, I have tested your case. I did try to convert your “source.xls” file to Pdf file, it took a lot of time for the conversion, the performance goes down considerably. We need to investigate why it is taking long time and analyze other issues as well. I have logged your issue for investigation into our issue tracking system with an id: CELLSNET-22880. We will get back to you soon to figure your issue out.
Thank you very much for sharing the sample PDF files. I have logged this issue as PDFKITNET-22901 in our issue tracking system. Our development team will investigate it in detail and you’ll be updated via this forum thread once it is resolved.
Regarding CELLSNET-22880 issue, it takes about 25 minutes to convert it to pdf file on our end. The pdf file contains about 4000 pages or so. Also MS Office’s add-ins converts this file in 10-12 minutes. The size is also gone very up for the generated PDF file for both Aspose.Cells API or Office’s add-ins for Excel to PDF conversion.
We can reduce memory usage to some extent, but could not evaluate how to decrease the conversion time. We will continue to look into it and once we have any update,we will let you know about it.
Thanks for the quick replies on these issues. I am just following up to see if any progress has been made on the development side, or if there is a way for me to check on the status of the tickets that were opened.
Specifically, those were PDFKITNET-22901 and CELLSNET-22880.
We are still evaluating the purchase of the suite and are interested in seeing a resolution on those items. Thanks again.
I would like to share with you that our team is working on the issue logged as PDFKITNET-22901; however, I’m afraid, it is not yet resolved. Nevertheless, I have asked our development team to share the ETA of this issue. You’ll be notified via this forum thread as soon as we get a clear idea of the time required for the resolution.
Thanks for the feedback on these two issues. I’ve downloaded Aspose.Cells 5.2.2 and have retested my scenario and unfortunately am seeing the same behavior. I have verified I was using the correct version, as the Aspose.Cells.dll was not located in the bin folder, and only the 5.2.2 assembly was in the GAC.
I ran the test twice and am pasting the 2nd test run below. Both tests behaved similarly enough that I am only including 1 result:
Run 2 – started around 11:03am, starting memory at 292MB (w3wp.exe)
> Converting the spreadsheet to pdf (Aspose.Cells)
~25min, ending at 11:28, peak memory usage of 1.8GB
Resulted in 16.7MB pdf
Appending the converted spreadsheet to another pdf (Aspose.Pdf.Kit)*
~23min, ending at 11:51, constant memory usage at 420MB
Resulted in 305MB pdf
The Aspose.Pdf.Kit assembly was unchanged in this test and there is already an open unresolved ticket for that so I am merely providing those results as I covered it as part of my test.
rhoalev: