Free Support Forum -

Table Row height calculations differ on Docker (and appear to be incorrect)

In my team’s use case, we utilize the Row Heights on the Table to calculate whether to split our content onto a new slide (to prevent overflow). This seemed to be very accurate until we started running out of a Docker container. Since then, some Row Heights have been calculated differently (either the same or increased heights across the board) within Aspose.Slides even though it’s generating the exact same content.

It appears this may be linked to Table Cells that have content that is close to being word-wrapped. Even though in the actual slide output there is no word wrapping, if the words run up against the margins that seems to be when the extra height gets calculated. So there seems to be a discrepancy between calculated output and actual output.

Let me know if you need any further info or if any of that is unclear. Thanks!


Please provide the working sample project along with source file. Please also share the docker details and version of Aspose.Slides that you have used on your end. Please also try using latest Aspose.Slides 20.10, if you are using an older version. Please do share the snapshot of the claim that shows that row height is wrongly calculated on your end.

We are using Docker version 19.03.12, build 48a66213fe, Linux containers. Aspose.Slides is on 19.2 (we did try running against the latest version to see if the issue would be fixed, but had the same result).

Attached screenshots of outputs. One example of row height discrepancies: the “Employee + Child(ren)” row had row height 18 when debugging the NON_DOCKER_EXAMPLE. When running in Docker (DOCKER_EXAMPLE1, DOCKER_EXAMPLE2), the row height was 26.4 even though the output is identical (besides the page break which is only a result of the errant row heights). DOCKER_EXAMPLE_1.png (58.5 KB)
DOCKER_EXAMPLE_2.png (29.3 KB)

I can work on getting a standalone sample project up and running


As requested earlier, please provide the information requested in my previous post.

Yes, this will be helpful.

Here is the sample solution. Thanks

EDIT: for further context, you’ll notice when you run in Docker-Compose vs as a Windows process, the last line of output.pptx will be missing in the former. (I did not port over the logic to split that row into a new page like the example screenshots show, just the logic to remove it when it detects an overflow)


I have created an issue with ID SLIDESJAVA-38341 in our issue tracking system to further investigate and resolve the issue. This thread has been linked with the issue so that you may be notified once the issue will be fixed.

@mudassir.fayyaz Just to be clear, this is using Slides .NET not Slides Java.

@mudassir.fayyaz Additionally, if there any workarounds identified for this issue (short of a full bug fix) that can be used in the interim, feel free to let me know that as well. Thanks!


The concerned .NET based ticket for this is SLIDESNET-42233. One thing you may check is that what scaling percentage you have got for your display (if there is). Is it above or below 100%. You can set that to 100%. Its only a rough idea that may help but proper solution will follow after investigation.

@mudassir.fayyaz It was set at 125%, but I tried setting it to 100% and am still seeing the same behavior as before when I generate presentations. Worth noting that this same issue happens in deployed environments, so I don’t believe it to be specific to my local configuration.


This was a suggestion that I shared that you may check. The concerned issue has been added in our issue tracking system and we will be able to share the feedback as soon as the issue will be addressed.