when exporting XLSX files with fixed rows to HTML, the generated CSS uses a comma as the decimal separator (e.g., top:13,25pt) instead of a dot, which is invalid in CSS.
System Language is German.
CultureInfo of the thread/workbook is set according to the documents language and is needed for dates and other localized formatsettings.
var lic = new License();
lic.SetLicense(@"S:\Aspose.Total.NET.lic");
var workbook = new Workbook(@"S:\tmp\in.xlsx");
// Set culture for formatting
var docCulture = new System.Globalization.CultureInfo("DE_DE");
Thread.CurrentThread.CurrentCulture = docCulture;
Thread.CurrentThread.CurrentUICulture = docCulture;
workbook.Settings.CultureInfo = docCulture;
workbook.Save(@"S:\tmp\out.html");
Thank you for your help
Attached Files for in.xlsx, out.html: example.zip (15.5 KB)
Based on limited evidence (treat as hypothesis), here is a cautious take: Summary
When exporting a workbook that contains frozen panes to HTML, Aspose.Cells formats the numeric values that describe pane positions (e.g., the top and left values in the generated CSS) using the culture that is active for the thread or the workbook (Workbook.Settings.CultureInfo). If the active culture uses a comma as the decimal separator (such as German), the CSS is emitted with commas (e.g., top:13,25pt), which is not valid CSS.
Why it happens
The HTML renderer does not convert these layout numbers to a culture‑independent format. It simply writes the numbers using the current CultureInfo, so a culture that formats decimals with a comma produces invalid CSS.
What to do next
Verify you are using the latest Aspose.Cells build – the issue may have been addressed in a newer release. Check the release notes or contact Aspose support to confirm.
Try a temporary invariant‑culture export (this is a common workaround for culture‑related formatting issues, but it is not guaranteed to fix every case). Example pattern:
using System.Globalization;
using System.Threading;
using Aspose.Cells;
var wb = new Workbook(@"S:\tmp\in.xlsx");
// Preserve original cultures
var originalThreadCulture = Thread.CurrentThread.CurrentCulture;
var originalWorkbookCulture = wb.Settings.CultureInfo;
// Switch to invariant culture for the HTML save
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;
wb.Settings.CultureInfo = CultureInfo.InvariantCulture;
wb.Save(@"S:\tmp\out.html", SaveFormat.Html);
// Restore original cultures
Thread.CurrentThread.CurrentCulture = originalThreadCulture;
wb.Settings.CultureInfo = originalWorkbookCulture;
This forces numeric values in the CSS to be written with a dot (.) as the decimal separator while leaving other cell formatting unchanged.
3. If the problem persists, open a support ticket with Aspose, attach the sample workbook and the generated HTML, and mention the culture‑related decimal‑separator issue. Provide the exact Aspose.Cells version you are using.
4. Document any workaround you adopt so future maintainers understand why the culture is altered during the HTML export.
Note: The above workaround is based on typical handling of culture‑dependent formatting in Aspose.Cells, but the definitive fix may depend on the specific library version. Always test with your actual files and environment.
Please validate this behaviour with your exact SDK version and a minimal repro, as support can vary by release.
I tested your scenario using the provided template XLSX file and sample code snippet, but I was unable to identify any issues with the output HTML file. What exactly is the attribute/tag name to check for the culprit incorrect decimal separator? I am currently using US-English locale/regional settings to process the code and view the resulting HTML. Would you like me to set the OS locale settings to “German” to observe the issue regarding the incorrect decimal separator in CSS? Additionally, could you kindly share some screenshots highlighting the problematic areas in the source of the generated HTML? This would assist us in evaluating your issue more accurately, allowing us to log the appropriate tickets in our database.
here is a screenshot highlighting the issue in the html file: image.png (18.7 KB)
Those Table rows get their height attribute set correctly, but their top attribute is set with the incorrect separator which leads to the unwanted behavior.
I have attached a gif to show the behavior with broken top offsets: chrome_EPJo8YyATH.gif (296.7 KB)
The only row which is fixed correctly had no decimals in their top offset.
Setting OS locale to “German” should reproduce the issue.
I am able to reproduce the issue as you mentioned by using your template Excel file and sample code snippet. I found incorrect decimal separator (top attribute is set with the incorrect separator) in CSS for fixed rows when exporting XLSX to HTML.
We require thorough evaluation of the issue. We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.
Issue ID(s): CELLSNET-59470
You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.
Your issue has been resolved. The fix will be included in an upcoming release (Aspose.Cells v25.12) that we plan to release in the first half of December 2025. You will be notified when the next version is released.
The result after applying the fix is attached for your review：output.zip (5.0 KB)
Please validate this behaviour with your exact SDK version and a minimal repro, as support can vary by release.