@IOZ
Summary
When you replace a footer placeholder with a string that starts with a digit (e.g., “4 Testdokument …”), the first page (odd) footer becomes huge because the leading digit is interpreted as a font‑size code by Aspose.Cells. The other footers are not affected because they are stored in a different XML element.
Why it happens
Excel’s footer syntax uses an ampersand (&) followed by a number to change the font size (e.g., &12 → 12 pt). In the XLSX XML the footer text is stored as plain text, but Aspose.Cells parses the string for formatting codes. If the replacement text begins with a numeric character, the parser mistakenly treats that digit as a size token even though there is no preceding &. The parsed size is added to the default font size, which makes the text appear very large. This parsing is applied only to the <oddFooter> element, which explains why only the first‑page footer is affected.
What to do next
- Check your Aspose.Cells version
- Open
packages.config or the NuGet manager and note the exact version you are using.
- Look at the release notes for newer versions – a fix for footer parsing may already exist. If a newer version is available, upgrade and retest.
- Verify the behaviour after an upgrade
worksheet.PageSetup.Footer = worksheet.PageSetup.Footer
.Replace("((Dokumentenname))", fileName);
workbook.Save("out.pdf", SaveFormat.Pdf);
If the large‑font issue disappears, the problem was fixed in the newer build.
- Work‑around if you cannot upgrade
- Prepend a non‑numeric character or a space so the first character is not a digit:
string safeName = " " + fileName; // leading space prevents size parsing
worksheet.PageSetup.Footer = worksheet.PageSetup.Footer
.Replace("((Dokumentenname))", safeName);
- Or explicitly set the font before the number using Excel’s escape sequence:
string safeName = "&\"Arial,Regular\"&11 4 Testdokument BFO IOZ";
worksheet.PageSetup.Footer = worksheet.PageSetup.Footer
.Replace("((Dokumentenname))", safeName);
Both approaches stop the parser from treating the leading digit as a size specifier.
- Inspect the generated XML (optional)
- Save the workbook as XLSX, unzip it, and open
xl/worksheets/sheetX.xml.
- Look at the
<oddFooter> element. If you see something like &4 Testdokument … the digit has been turned into a size code.
- If the issue persists
- Gather the following information for a support request:
- Exact Aspose.Cells for .NET version.
- Minimal reproducible code that performs the placeholder replacement and saves the file (PDF or XLSX).
- The original footer string before replacement.
- Any
PdfSaveOptions you use.
- Submit the details to Aspose Support (or your internal support channel). The product team can confirm whether this is a bug and provide a fix or a more permanent workaround.
Note: The explanation above is based on the known Excel footer formatting rules and the observed behaviour you described. The official Aspose documentation does not currently contain a specific article about this exact scenario, so the suggested work‑arounds are the most reliable way to avoid the problem until a library update addresses it.
I could not fully verify this explanation against the retrieved sources. Please double-check the behaviour in your environment and confirm the exact SDK/version.
SDK version unclear — refer to the official release notes before applying this guidance.