Images Breaking When Converting to PDF

Hello. We are running into a problem where occasionally the letterhead image will break when being converted to PDF and replaced with a red X.

There are two concerns that we have:

  1. Obviously, we would like to have the conversion process work rather than break the image occasionally.
  2. Despite our efforts, we were not able to find a way to get the Aspose.Words library to give us any indication that such a failure occurred. We tried implementing a warning callback, however the messages produced were similar both for the successful conversions as well as the failed. We were left with having to use Aspose.Pdf to open the converted document and search for the broken images by doing a byte comparison between a byte array sample of the red X image and each image in the document.

We have included a sample application to replicate the problem.

If you have any suggestions, they would be welcome. Otherwise, we would like to request that a better mechanism for detecting these sorts of failures be made available (in addition to the success rate being improved, of course).

Thank you for your assistance and hard work!

AsposeTryToBreakThings.zip (56.8 KB)

@tbihlajama,

We tested the scenario and have managed to reproduce the same problem on our end. For the sake of correction, we have logged this problem in our issue tracking system. The ID of this issue is WORDSNET-17338. We will further look into the details of this problem and will keep you updated on the status of correction. We apologize for your inconvenience.

@tbihlajama,

Regarding WORDSNET-17338, it is to update you that we have completed the analysis of this issue. The GDI+ may throw an Out Of Memory exception when loading this image under heavy load as in your example. We do not think that we could do something about it with GDI+. And it is a rare case to look for some other image processing. Also, the Aspose.Words throws the warning “Unsupported image format.” in this case.

As a workaround to the problem you can down-sample the problematic image to acceptable size by yourself.

Also, about “Unsupported image format.” the text is a bit confusing in this case. We think we could only write a more specific text on this Out Of Memory exception.

@awais.hafeez

Thank you for the investigation and the response. Regarding the “Unsupported image format.” warning, we seemed to find with our test that the message occurred even when the document converted without any problems. Are you able to confirm this?

Also, we agree that it would be nice to have a more specific warning or error come from Aspose.Words so that we could at least reliably detect that a problem occurred and respond accordingly. Right now the only “reliable” way we have of testing is checking each image in the resulting document for an image that matches the byte array of the “red x” image, which is less than ideal.

Thank you again for your assistance and support.

@tbihlajama,

We will keep you posted on further updates.

Can you please share input Word document and simple application (source code) to reproduce this specific issue on our end?

@awais.hafeez

Thank you for the response. Using the sample application that was attached to the original post (which includes a sample document): If I run the Parallel.For loop 1000 times I get a different number of OutOfMemoryExceptions, Unsupported image format messages, and malformed documents.

For example, one test run with a Parallel.For loop running 1000 times gave me the following results:

484 “Unsupported image format” messages
695 Out of memory exceptions
599 Malformed docs (image was replaced with Red X)

I would expect the number of “Unsupported image format” messages to be the same as the number of malformed documents, otherwise, we can’t reliably use that to determine if the conversion succeeded in all respects.

Thanks again for the assistance.

@tbihlajama,

Thanks for the details. We will keep you posted on further updates and let you know when WORDSNET-17338 is resolved.

The issues you have found earlier (filed as WORDSNET-16496) have been fixed in this update