Aspose renders the same worksheet to images in different size in Session 1 vs Session 0

Hi,



This one is quite a weird and complex one and difficult to replicate but causes massive problems.

Aspose being server-side compatible we run it inside a service; in Windows this gives the process session 0. Here is a quick article explaining sessions in Windows:

https://blogs.technet.microsoft.com/askperf/2007/07/24/sessions-desktops-and-windows-stations/

However, on a certain hardware Aspose.Cells renderer behaves differently when run in session 0 as opposed to session 1. This causes the output image in different size in session 0 and session 1.



To test, you can use the following code:



var book = new Workbook(“Test.xlsx”);

Worksheet sheet = book.Worksheets[0];

sheet.PageSetup.PrintArea = “A1:B2”;

sheet.PageSetup.LeftMargin =

sheet.PageSetup.RightMargin = sheet.PageSetup.TopMargin = sheet.PageSetup.BottomMargin = sheet.PageSetup.HeaderMargin = sheet.PageSetup.FooterMargin = 0;

var options = new ImageOrPrintOptions

{

ImageFormat = ImageFormat.Png,

OnlyArea = false,

OnePagePerSheet = true,

TextRenderingHint = TextRenderingHint.ClearTypeGridFit

};

new SheetRender(sheet, options).ToImage(0, “out.png”);



In session 1: The size of “out.png” is 194194.

In session 0: The size of “out.png” is 200
194.



I had tried to set DPI in rendering options or in CellHelper.DPI, and had also tried to use different image format but the results were still different, and the difference was more significant if rendering it in .EMF format.



To run the program in session 0 you can use the following command as administrator to open up a session 0 session



psexec.exe -s -i 0 cmd.exe



Now the caveat here is that not all hardware we run it on produces the incorrect result. The problem only occurs on a specific hardware configuration. It is reproducible each time but only on that specific hardware (on all machines with that hardware configuration).



So it would be nice if you could check with engineers what the probable cause of this could be.



Best regards,

Hi John,


Thank for sharing the problem description.

I have given this scenario a try on Windows 7 x64 however, I am not able to see any difference in the image size generated from session 0 or without it. I will surely discuss this matter with the product team but I require more information to present this case. For instance, you haven’t mentioned any details about the particular hardware that allows you to replicate the said problem. Please provide as much details as you can in terms of hardware as well as software (operating system version/architecture, installed frameworks, display settings, locale and so on). Have you tried the latest version of Aspose.Cells for .NET 8.8.2.7? If not, could you please provide feedback against it?

Hi Babar,



Thanks for your reply.



I’ve attached the exported hardware and OS/Locale information of my PC.



I’m using .NET Framework 4.5.1 and I’ve tested from Aspose.Cells 8.6.0 to 8.8.2 and all of them had this issue. (I didn’t test with older versions but I guess they may also have)



I also tested with other machines which have different Hardware but with the same software environment and the issue didn’t happen.



One thing might be helpful for your investigation is that the dpi (Image.HorizontalResoluton/Image.VerticalResolution) of output images in Session 1 and Session 0 are different (for .EMF images in session 1 it is 72.03544 while in session 0 it is 81.27999).



Another thing which might be important is that this issue only happens with SheetRender.ToImage(). When using Chart.ToImage() to render a single chart, the size and dpi of the output image in two sessions are exactly the same (for .emf chart images the dpi are both 95.97222).



I hope this information would be of any help for your investigation.



Thanks very much,

Hi John,


Thank you for sharing more details. I believe the shared information will help us evaluate the scenario. Before I move forward to presented this case to the product team, I need following test results.

  1. We have recently addressed a problem related to the EMF rendering using SheetRender class so we need to make sure if this problem has been resolved or still reproducible with current latest revision of the API. Could you please re-execute your tests against the latest version of Aspose.Cells for .NET 8.8.2.8 (compiled against .NET Framework 4.0) and share the resultant PNG & EMF files generated from session 0 & 1?
  2. As you have mentioned that you have tried setting the DPI value in past but the problem was not resolved. Please note, you need to set the CellsHelper.DPI property at the start of your application, that is; before invoking any other objects from Aspose.Cells for .NET library. Could you please try setting the DPI value against Aspose.Cells for .NET 8.8.2.8 and share the results? The code will look as follow.

C#

CellsHelper.DPI = 96;

//Set License

var book = new Workbook(dir + “Test.xlsx”);
Worksheet sheet = book.Worksheets[0];
sheet.PageSetup.PrintArea = “A1:B2”;
sheet.PageSetup.LeftMargin =
sheet.PageSetup.RightMargin = sheet.PageSetup.TopMargin = sheet.PageSetup.BottomMargin = sheet.PageSetup.HeaderMargin = sheet.PageSetup.FooterMargin = 0;
var options = new ImageOrPrintOptions
{
ImageFormat = ImageFormat.Png,
OnlyArea = false,
OnePagePerSheet = true,
TextRenderingHint = TextRenderingHint.ClearTypeGridFit
};
new SheetRender(sheet, options).ToImage(0, “out.png”);
options.ImageFormat = ImageFormat.Emf;
new SheetRender(sheet, options).ToImage(0, “out.emf”);


Thank you for your cooperation.

Hi Babar,



Thanks for providing the code and .dll file for testing.



I’ve attached the test results using “session 0 vs session 1” and also “setting DPI vs without setting DPI” with 8.8.2.8.



I could see setting DPI in advance will make the .png file look the same. While it made the .emf image trimmed (You can see output is trimmed in “outSession0CellHelperDPI96.emf”, some text is missing).



And when inserting “outSession1CellHelperDPI96.emf” and “outSession0CellHelperDPI96.emf” into Word, you will find the size is still different (session 1 is 6.846.88cm and session 0 is 6.066.09cm) even with setting DPI.



As for what I mentioned “setting the DPI value in past but the problem was not resolved”, actually I remember I met the same issue with .emf output when setting DPI to 96 using Aspose.Cells 8.6.3 and above, so I believe the trim does not only happen in this 8.8.2.8 version.



Also without setting DPI, the size of images including .emf and .png remain different, files are also provided in the attachments.



I hope that these test results help. As this issue is important to me, please let me know if you need more test results from my side.



Thanks,

Hi again,


Thank you for the test results. We are currently in a discussion with the concerned member of the product team, and we will shortly get back to you with updates in this regard.

Hi John,


This is to update you that I have logged a formal investigative ticket with Id CELLSNET-44531. Moreover, we will require your active participation & cooperation to perform tests on the problematic machine in order to isolate the problem cause.

Please check and execute the following code in Session 0 & 1 without setting the CellsHelper.DPI property. The code should produce a log file (log.txt) in the same folder as of executable file. Please share it here for further analysis. Thank you.

C#

StringBuilder sb = new StringBuilder();
sb.AppendLine("Version: " + CellsHelper.GetVersion());
sb.AppendLine("DPI: " + CellsHelper.DPI);

var book = new Workbook(“Test.xlsx”);
Worksheet sheet = book.Worksheets[0];
Cells cells = sheet.Cells;

sb.AppendLine("Column A width in pixel: " + cells.GetColumnWidthPixel(0));
sb.AppendLine("Column B width in pixel: " + cells.GetColumnWidthPixel(1));
sb.AppendLine("Column A width in inch: " + cells.GetColumnWidthInch(0));
sb.AppendLine("Column B width in inch: " + cells.GetColumnWidthInch(1));
sb.AppendLine(“Row 1 height in pixel:” + cells.GetRowHeightPixel(0));
sb.AppendLine(“Row 2 height in pixel:” + cells.GetRowHeightPixel(1));
sb.AppendLine(“Row 1 height in inch:” + cells.GetRowHeightInch(0));
sb.AppendLine(“Row 2 height in inch:” + cells.GetRowHeightInch(1));

sheet.PageSetup.PrintArea = “A1:B2”;
sheet.PageSetup.LeftMargin =
sheet.PageSetup.RightMargin = sheet.PageSetup.TopMargin = sheet.PageSetup.BottomMargin = sheet.PageSetup.HeaderMargin = sheet.PageSetup.FooterMargin = 0;

var options = new ImageOrPrintOptions
{
ImageFormat = ImageFormat.Png,
OnlyArea = false,
OnePagePerSheet = true,
TextRenderingHint = TextRenderingHint.ClearTypeGridFit
};
SheetRender sr = new SheetRender(sheet, options);
sb.AppendLine("Page size in pixel: " + sr.GetPageSize(0));
sr.ToImage(0, dir + “out.png”);

File.AppendAllText(“log.txt”, sb.ToString());
sb.Clear();

Hi Babar,



Thanks for your update.



I’ve attached the test results using Aspose.Cells 8.8.2.8.



As you requested, I tested it without setting DPI in advance in both session 1 and session 0.



Moreover, I’ve also attached the log results of pre-set DPI in advance in session 0 and also provided you all the .emf outputs for your reference. (You can see after presetting DPI, log.txt in session 0 are all the same as log.txt in session 1. But the .emf output is different (trimmed))





Thanks,

Hi again,


Thank you so much for your prompt response. Could you please execute the following statements and share the DPI values returned by the process in both sessions? You may take snapshots of the console windows for easement and share them here.

C#

using (Bitmap b = new Bitmap(1, 1))
{
using (Graphics g = Graphics.FromImage(b))
{
Console.WriteLine("DPIX: " + g.DpiX);
Console.WriteLine("DPIY: " + g.DpiY);
}
}

Hi,



I’ve attached the results.



Thanks,

Hi,


Thank you for the results. I have forwarded these details to the product team for review. Please note, we will first investigate the problem of image size in PNG format then move to more complex scenario such as EMF trimming.

Hi again,


This is to update you regarding the further investigation of the said scenario. As per your recently shared snapshots, the Session 0 has different DPI than the Session 1 which is causing the Aspose.Cells APIs to calculate column widths incorrectly, consequently causing different image size as compared to the one generated in Session 1. You can avoid this problem by explicitly setting the DPI with the help of CellsHelper.DPI property. You have already tested that it fixes the image size problem (ref). However, as per your results, setting the DPI also causes the trimming of the EMF images so we are currently working to fix the problem for EMF format.

That said, could you please investigate, why the Session 0 has different DPI than Session 1?

Hi John,


This is to update you that the problem related to the EMF trimming has been resolved. We will shortly share the fix here for your testing. As soon as the next revision of the Aspose.Cells for .NET API is available, we will inform you via this thread.

The issues you have found earlier (filed as CELLSNET-44531) have been fixed in this update.


This message was posted using Notification2Forum from Downloads module by Aspose Notifier.

Hi,



Thanks very much for the updates.



I’ve checked it and found it indeed made the size of the image outputs exactly the same between sessions and the trim of sheet .emf was resolved.



But I noticed another two new issues.



The first issue is that CellsHelper.DPI can only be set once. Any further modification on CellsHelper.DPI does not work after accessing the property.



Sample code:

Console.WriteLine(CellsHelper.DPI);

CellsHelper.DPI = 120;

Console.WriteLine(CellsHelper.DPI);

“CellsHelper.DPI = 120” doesn’t work because CellsHelper.DPI was read before.



Or:

CellsHelper.DPI = 120;

Console.WriteLine(CellsHelper.DPI);

CellsHelper.DPI = 96;

Console.WriteLine(CellsHelper.DPI);



“CellsHelper.DPI = 96” doesn’t work because CellsHelper.DPI was modified before.



The second thing is the chart image in session 0 looks wrong after setting the DPI .

Code:

CellsHelper.DPI = 96;

var book = new Workbook(@“test.xlsx”);

Worksheet sheet = book.Worksheets[0];

var options = new ImageOrPrintOptions

{

ImageFormat = ImageFormat.Emf,

OnlyArea = false,

OnePagePerSheet = true

};

sheet.Charts[0].ToImage(@“out.Emf”, options);



There is significant difference between the out image and the original chart in session 0 (in the machine where session 0 has 120 DPI). While the tables are fine (but tables are rendered by SheetRender).



I’ve attached the output image in session 0 and session 1 for your reference.



Thanks,

Hi John,


Thank you for your feedback. It is good to to know that you are no longer facing the EMF trimming issue. Regarding your recent concerns, the value for CellsHelper.DPI can be set only once which will last through out the application life cycle. Why do you need to reset the DPI value?

I have noticed the difference in chart’s images. The image generated in Session 0 (with CellsHelper.DPI set to 96) seems to be incorrect. Could you please repeat the test on Session 0 against the latest revision of the Aspose.Cells for .NET 8.8.3.2? Please generate 2 images in Session 0, one by setting the DPI to 96 and other without it.

Hi Babar,



Thanks for your reply.



Yes normally we shouldn’t need to reset DPI, it was only because the chart image works better with DPI value 120 in my session 0 (where the DPI is 120 by default). So I was thinking of rendering sheet by 96 DPI and when rendering charts I change the value back to 120. As long as chart image using 96 is correct, I will not need to reset DPI.



I tested with Aspose.Cells 8.8.3.2 you provided, and attached the results.



I found the labels were no longer overlapped that much in 8.8.3.2 when setting DPI to 96 in session 0, but the second line of labels were missing and still a bit overlapping (you can find part of horizontal axis ticklabel “j” is missing). Without setting DPI in session 0, everything looked fine but the size is larger.



In session 1, setting DPI to 96 or not will both produce an image in which two lines of labels were displayed correctly, but still a bit overlapping on horizontal axis ticklabels.



I hope these results help.



Thanks very much

Hi John,

Thank you for your feedback.

ServerSide527:
Yes normally we shouldn't need to reset DPI, it was only because the chart image works better with DPI value 120 in my session 0 (where the DPI is 120 by default). So I was thinking of rendering sheet by 96 DPI and when rendering charts I change the value back to 120. As long as chart image using 96 is correct, I will not need to reset DPI.

I am afraid, the current implementation does not allow to reset the CellsHelper.DPI in a single application cycle. We will try our best to fix the problem for chart rendering so that you do not need to reassign the aforementioned property.

ServerSide527:
I tested with Aspose.Cells 8.8.3.2 you provided, and attached the results. I found the labels were no longer overlapped that much in 8.8.3.2 when setting DPI to 96 in session 0, but the second line of labels were missing and still a bit overlapping (you can find part of horizontal axis ticklabel "j" is missing). Without setting DPI in session 0, everything looked fine but the size is larger.

I have tried this scenario by setting the Display Size of my machine to 100%, 125% & 150%, however, I was not able to replicate the above mentioned problems on my side. Please note, I have used the latest revision of the API, that is; 8.8.3.3 at the moment for my testing. Moreover, we have recently fixed a number of chart rendering problems with this revision of the API so it is quite possible that the problem has already been rectified. Anyway, I have logged an investigative ticket with Id CELLSNET-44564 in our bug tracking system for product team's review. Still, I would request you to re-execute all tests against Aspose.Cells for .NET 8.8.3.3 and share your results here.

ServerSide527:
In session 1, setting DPI to 96 or not will both produce an image in which two lines of labels were displayed correctly, but still a bit overlapping on horizontal axis ticklabels. I hope these results help.

Please check the attached archive for the image 100PercentDisplay-withoutsettingDPIto96.Emf which I have generated in Session 1 at normal Display Size (100%) by setting the vertical & horizontal to 300. Due to high resolution, the generated image is enlarged, and you can see that overlapping problem is not present. If you generate the image without setting the resolution (your shared snippet) the resultant image is too small in size and appears that most of the contents are overlapping. Please check this scenario against the latest revision as well. In case you see some problem, please share a snapshot highlighting the problematic area in the Aspose.Cells generated image(s).

Hi Babar,



Thanks very much for your quick response.



I’ve just tested with Aspose.Cells 8.8.3.3 but all the issues remains (the outputs were exactly the same as what I attached last time using 8.8.3.2). To ensure I used the correct version, I also printed out the version number using CellsHelper.GetVersion() and it suggested it is 8.8.3.3.



Regarding what I mentioned the “overlapping on horizontal ticklabels”, I’ve attached a screenshot and highlighted the problematic area for you. You can see it was a lot better than when using 8.8.3.0 but still a little overlapping remains. This was not fixed in 8.8.3.3 either.



Thanks,

Hi John,


Thank you for highlighting the problematic area in the rendered chart, and sorry I was not able notice the said problem earlier. I have logged a separate ticket in this regard with Id CELLSNET-44569 for product team’s review. Please spare us little time to properly analyze the problem cause, and get back with updates in this regard.

C#

var book = new Workbook(dir + “test (3).xlsx”);
Worksheet sheet = book.Worksheets[0];
var options = new ImageOrPrintOptions
{
ImageFormat = ImageFormat.Emf,
OnlyArea = false,
OnePagePerSheet = true,
VerticalResolution = 300,
HorizontalResolution = 300
};
sheet.Charts[0].ToImage(dir + “100PercentDisplay-withoutsettingDPIto96.emf”, options);