Many thanks for your update.
Thanks for the information. From techinical stand of view I understand sometimes it would be more difficult to handle such case if the layout is in a ‘critical state’. However, the end users (clients) does not know such concept, they may adjust the worksheet in Excel and when they are satiesfied with its looking (without knowing it is ‘critical’ or not), they send to the programme for rendering. In that case, the output looks differently.
As we rely on the accuracy of the output from Aspose libraries, we still expect Aspose to mimic the same behaviour as Office, so that both developers and end users have less surprise over the output. I understand it is difficult to address every single case, but I think it might worth to address and take them into account in future so that Aspose.Cells will be more reliable.
Thanks for the implementation. As an image type EmfOnly usually has better compatibility but is quite old and has much poorer quality than EmfPlusDual.
As in a program, we cannot predict whether the output image has to be ‘EmfOnly’ in order to make it compatibile with word pdf option, we will have to use the option for all the images.
However, only very few images actually have this compatibility issue (I have used Aspose extensively and this is the only output that caused the word save as issue), I don’t think it’s very viable to reduce the image quality in the whole programme. So, it would still be great to understand what exactly happened to this image, so that we can get around the issue without losing the quality of every other image output, as the output itself is still very concerning. The users may face a blocking issue when they want to save the document to pdf, as the dialog does not tell that it is because of the image so it would be very difficult to figure out. In that case, even if we may not fix it, we can know where the limiation is and set ‘EmfOnly’ on these type of worksheet specifically.