Prior to upgrading to version 9.4 I was able to instantiate a Document object using a constructor that takes a memorystream. Ver. 9.4 introduced a breaking change because now I get an error message that only a FileStream object can be used in the Document constructor. This seems to be to be an arbitrary and unnecessary restriction. It forces me to write the contents to a disk file and then the constructor reads it back.
Hi Stephen,
Thanks for your inquiry. We have double checked the Document class constructor with MemoryStream parameter and it is working fine. We will appreciate if you please share some sample code to replicate the issue, we will look into it and will provide you more information accordingly.
FileStream fs = new FileStream(myDir + "input.pdf", FileMode.Open, FileAccess.Read);
byte[] tmpBytes = new byte[fs.Length];
fs.Read(tmpBytes, 0, Convert.ToInt32(fs.Length));
MemoryStream mystream = new MemoryStream(tmpBytes);
Document pdf22 = new Document(mystream);
pdf22.Save(myDir + "MemoryStreamTest.pdf");
Best Regards,
Hi Stephen,
Please note that for testing purposes, we have used VisualStudio 2012 project with target platform as .NET Framework 4.0, running over Windows 7 (x64). Please note that we have used Aspose.Pdf.dll from net4.0 folder present over Aspose.Pdf for .NET installation directory.
Can you please share some details regarding your working environment.
I have more information on this issue. The application is to dragdrop an email message from Outlook (using Aspose.Email), and the content data is coming from a MapiMessage object and is HTML format. My environment is Win7 64-bit, VS2010 / VB.Net, targeting Framework 4 (full).
In the HtmlLoadOptions I am setting UseNewConversionEngine = False. However, prior to ver. 9.4 I was able to set this to True (even though the documentation states that there may be bugs). Now, with Ver. 9.4, setting UseNewConversionEngine = True with my content produces an exception error message filled with binary garbage. However, I am not complaining about that for this issue - just mentioning as an aside. Again, my code worked OK prior to upgrade to pdf 9.4.
I hope this additional information is helpful. Please see the attached screen grab.
Stephen
Hi Stephen,
Thanks for your feedback. Please note in Aspose.Pdf for .NET 9.4.0, UseNewConversionEngine default value is true. So by default API uses new Engine for the conversion. If you explicitly set it to false then it uses Old Engine and throws the stream exception. Please either do not use this property or set it to true.
Furthermore, please share exception detail you are facing while setting UseNewConvesionEngine to true and we will appreciate it if you please also share sample HTML text causing the error. It will help us to replicate the issue.
We are sorry for the inconvenience caused.
Best Regards,
Good news… I believe I found the problem (or at least a fix) in my code. I was trying to discover what was causing the binary garbage in the exception message and I guessed that the string to byte array encoding might be involved. I was using the UTF8 encoding class to convert the string containing the HTML body content into a byte array. When I switched to using ASCII encoding there is no error. So I am able to use the new conversion engine (default for 9.4) and a memorystream in the Document constructor. However, something did change with pdf 9.4 because previously using the UTF8 encoding did not cause an error.
By the way, even using the new conversion engine the document object construction process runs 3 - 5 seconds on a fast machine for a fairly simple HTML content. Why so much time?
Thank you,
Stephen
Hi Stephen,
Thanks for your feedback. It is good to know your initial problem is resolved. We will appreciate it if you please share your sample HTML causing issue with different encodings, we will test the scenario at our end and will provide you more information. Furthermore, we will also test the performance issue with your sample and update you accordingly.
We are sorry for the inconvenience caused.
Best Regards,