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.
We understand your concerns. We always try our level best to address each and every issue our users post. Sometimes we could not devise any reliable approach to resolve certain complex cases (posted by the users) - there might be certain limitations or other hurdles involved, but still we spend enough time (at regular intervals) and resources to try to find some better way around. Sometimes we are successful and sometimes not. And, alright, we will try to consider your specific or any outstanding issue to figure it out in future.
We have logged your points and concerns again your issue “CELLSNET-46451” into our database. We will analyze and try to provide more details about the culprit image for your reference.
For the issue “CELLSNET-46451”, after investigating your issue further, we found the arrow in the chart (specific to “+40.2%”) is causing the error. In Aspose.Cells, we use Pen.CustomEndCap to set the arrow properties. Now we cannot find any other method to replace Pen.CustomEndCap API. I’m afraid you need to remove the arrow or use EmfOnly for your case.
Many thanks for the investigations. This is helpful.
I’m a little surprised that an API from Microsoft’s System.Drawing (Pen.CustomEndCap) is not compatible with Microsoft Office Word, but it is good to understand where the problem is.
I will be very grateful if this issue can be fixed in the future, and thanks for finding the root cause here.
Thanks for the feedback. In near future, there is no such plan however you may please keep an eye on blog post every month which announces all the new features and enhancements in the newly released versions.
The issues you have found earlier (filed as CELLSNET-46451,CELLSNET-46518) have been fixed in Aspose.Cells for .NET v19.1. This message was posted using BugNotificationTool from Downloads module by Amjad_Sahi