Description
Aspose.Words does not correctly render EQ (Equation) fields of the form { EQ \o(, {text or whitespace with font borders}) }. Rendering issues occur when the EQ field contains whitespace or text that uses a font border.
Sample Docx:
sample.docx (16.3 KB)
Expected Result (as shown in Word 2010)
- Whitespace with a font border should be visible.
- Text with a font border should be enclosed by one unified border applied to the entire text segment.
Actual Result (Aspose Output):
- Whitespace with a font border becomes completely invisible in the rendered output.
- Text with a font border is rendered with separate borders around each character, rather than a single continuous border.
Code Sample:
using Aspose.Words;
new License().SetLicense($@"licensePath");
var doc = new Document($@"inputDocxPath");
doc.Save($@"outputPngPath");
Environment:
- .NET Framework 4.8
- Aspose.Words 25.12.0
Request for Clarification
Could you please advise whether this behavior is expected, or if support for proper font-border rendering within EQ fields may be considered for a future update?
@chenweii
What we see
You are converting a DOCX that contains a legacy EQ field of the form
{ EQ \o( , {text or whitespace with font borders}) }
When the field includes a space or text that has a font border, the rendered PNG (or PDF) shows:
- the whitespace disappears completely, and
- the border is drawn around each character separately instead of a single continuous border.
You are using .NET Framework 4.8 with Aspose.Words 25.12.0.
Is this expected?
No – the output you obtain is a limitation of the current rendering engine. Aspose.Words fully supports modern Office Math (OMML) equations, but it does not implement the layout logic for the \o (over‑strike) switch used in legacy EQ fields. Because the engine cannot interpret the over‑strike element, the whitespace (or the border) is either omitted or rendered per‑character [2].
Why it happens
- The field syntax
{ EQ \o(...) } is a legacy EQ field.
- The
\o switch tells Word to overlay one element on another (e.g., place a shape or a border under a space).
- Aspose.Words’ rendering pipeline does not contain the code that merges the over‑strike element with the surrounding text, so the result is either invisible whitespace or fragmented borders [2].
What you can do right now
-
Confirm the field type (optional, but useful for debugging):
foreach (Field field in doc.Range.Fields)
{
if (field.Type == FieldType.FieldEq)
Console.WriteLine($"EQ field code: {field.GetFieldCode()}");
}
-
Upgrade if possible – check the release notes of any newer NuGet package (e.g., 25.13.x). If a newer build adds support, the issue will disappear; otherwise the limitation remains.
-
Work‑around 1 – replace the legacy EQ field with a picture
Render the equation once in Word, save it as a PNG, and substitute the field with an inline Shape that contains that picture. The code snippet from the forum post shows the full process [2].
-
Work‑around 2 – migrate to modern Office Math (OMML)
If you can edit the source document, replace the legacy EQ field with an OMML equation (<m:oMath>). Aspose.Words renders OMML correctly, including any borders or over‑strike graphics [2].
-
Work‑around 3 – pre‑process the document
Write a small routine that removes the \o switch from the field code (leaving only the plain text) and then applies a custom border programmatically via Run.Font.Border on the resulting Run objects. This yields a single continuous border, though you lose the exact over‑strike layout.
Future support
The behavior you observed is a known limitation, and the Aspose.Words team is aware of the demand for full legacy EQ field rendering. While we cannot guarantee a specific release, the issue has been logged internally and will be considered for a future update. If you need to track progress, please open a support ticket referencing the field code and the version you are using; we will keep you posted on any roadmap changes.
Next steps for you
- Try one of the work‑arounds above (picture substitution or OMML migration).
- If none of them fit your workflow, open a support request with the sample DOCX attached so we can reproduce the issue on our side and prioritize it accordingly.
Feel free to share any additional details (e.g., exact field code, screenshots) if you need further assistance.
Thanks for your reply.
I am curious whether there is a way to replace an EQ field with an image. I noticed that when converting a DOCX to HTML, the EQ field is rendered as an image. Is it possible to replace the EQ field with an image while preserving the original rendered size of the field?
@chenweii
What you can do
Yes – the recommended way to keep the visual appearance of a legacy EQ field is to replace the field with an image (a Shape of type Image).
The image can be the exact picture you obtain when Word converts the EQ field to HTML, and you can size the shape to match the original field’s layout.
Step‑by‑step workaround (C#)
using Aspose.Words;
using Aspose.Words.Drawing;
using System.Linq;
// 1. Load the source document
Document doc = new Document(@"input.docx");
// 2. Iterate over a copy of the fields collection because we will modify the document
foreach (Field field in doc.Range.Fields.ToArray())
{
// Process only legacy EQ fields
if (field.Type == FieldType.FieldEq)
{
// -------------------------------------------------
// 2a. Prepare the picture that represents the whole equation
// (you can obtain this picture by letting Word save the EQ field as PNG/HTML)
string eqImagePath = @"eqImage.png";
// 2b. Create an Image shape
Shape picture = new Shape(doc, ShapeType.Image);
picture.ImageData.SetImage(eqImagePath);
picture.WrapType = WrapType.Inline; // keeps the picture in the same line as the field
// 2c. (Optional) Preserve the original rendered size
// The field’s original size can be approximated from its font size.
// Adjust the factor as needed for your document.
double fontSize = field.Start.Font.Size; // points
picture.Width = picture.Height = fontSize * 1.2; // points → size similar to the EQ field
// -------------------------------------------------
// 3. Insert the picture where the field was
Paragraph para = (Paragraph)field.GetAncestor(NodeType.Paragraph);
para.InsertAfter(picture, field.Start);
// 4. Remove the original EQ field
field.Remove();
}
}
// 5. Save the document (PNG, PDF, DOCX, …)
doc.Save(@"output.png");
Key points
- The code iterates over all
FieldEq objects, creates an inline Shape that holds the pre‑rendered picture, inserts the shape at the field’s position, and then removes the original field – exactly the workaround described in the forum post [2] and reiterated in the earlier response [1].
- By setting
WrapType = Inline the picture stays on the same line as the original field, which helps preserve the layout.
- The size of the picture can be tuned to the original rendering. A simple way is to base the shape’s
Width/Height on the field’s font size (field.Start.Font.Size). Adjust the multiplier (1.2 in the example) until the visual size matches what you see in Word/HTML.
What to do next
- Export the EQ field to an image (e.g., let Word save the document as HTML – the EQ field is already rendered as an
<img> tag) and use that file as eqImage.png.
- Run the snippet above on a copy of your document.
- If the size is not a perfect match, tweak the
picture.Width/picture.Height calculations (you can also read the image’s original pixel dimensions via picture.ImageData.ImageSize and convert to points).
This approach gives you full control over the visual output while avoiding the rendering limitation of the legacy \o over‑strike switch in Aspose.Words. If you need further assistance (e.g., exact size‑matching logic for a specific document), feel free to share a sample file and we can fine‑tune the sizing code.
@chenweii
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): WORDSNET-28916
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.
