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,
FileStream fs = new FileStream(myDir
- “input.pdf”, FileMode.Open, FileAccess.Read);<o:p></o:p>
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");
Hi Stephen,
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,
<o:p>We are sorry for the inconvenience caused.</o:p>
<o:p>
</o:p>
<o:p>Best Regards,</o:p>
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,