EQ Field Overstrike with Bopomofo Tone Marks Not Rendering Properly

Aspose.Words Product Family
,
1

Description:
Converting Word documents containing EQ fields like:

{ EQ \o(`,ㄓ ) }
{ EQ \o(ˊ,ㄑㄩㄥ ) }
{ EQ \o(ˇ,ㄋㄧㄠ) }
{ EQ \o(`,ㄩㄣ) }
{ EQ \o(˙,ㄉㄜ) }

results in missing tone marks (ˊ, ˇ, `, ˙) above or below Bopomofo phonetic text when using Aspose.Words.

Sample Docx:
bopomofo.docx (21.7 KB)

Expected Result (Microsoft Word Screenshot):
Tone marks should display correctly over or under the phonetic text, matching Word’s output (see attached screenshot).

2002×290 6.86 KB

Actual Result (Aspose Output):
In exported images, only Bopomofo text appears—accent marks are missing.

816×1056 3.56 KB

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.11.0

Possible Solution:
Is there a solution to fully support EQ field overstrike (\o) rendering for Bopomofo tone marks? If not, could this be considered for a future update?

2

@chenweii

Summary
Aspose.Words can read a legacy EQ field such as { EQ \o(...) }, but the rendering engine does not draw the over‑strike operator (\o). As a result, the tone marks that should appear above or below Bopomofo characters are missing in the PNG/PDF produced by Aspose.Words.

Why it happens

  • The EQ field is an older Word equation format. Aspose.Words parses the field (the FieldEQ class is available) but its renderer does not support drawing legacy EQ fields, especially the over‑strike operator that composes two characters on top of each other.
  • Microsoft Word’s own rendering engine handles this format correctly, which is why the expected output looks right when the document is opened in Word. The limitation is present in the current Aspose.Words releases.

What to do next

  1. Convert legacy EQ fields to Office Math (OMML) before rendering
    Office Math is fully supported by Aspose.Words, so the tone marks will be rendered correctly after conversion. One practical way to perform the conversion is to use Microsoft Word automation (requires Word to be installed on a machine that can run the conversion).
// 1. Open the original document with Word Interop
var wordApp = new Microsoft.Office.Interop.Word.Application();
var doc = wordApp.Documents.Open(@"C:\input.docx");

// 2. Upgrade all legacy EQ fields to Office Math (OMML)
doc.UpgradeLegacyMath(); // converts EQ fields to <m:oMath> elements

// 3. Save the upgraded document
string upgradedPath = @"C:\input_upgraded.docx";
doc.SaveAs2(upgradedPath,
Microsoft.Office.Interop.Word.WdSaveFormat.wdFormatXMLDocument);
doc.Close();
wordApp.Quit();

// 4. Load the upgraded file with Aspose.Words and export
var asposeDoc = new Aspose.Words.Document(upgradedPath);
asposeDoc.Save(@"C:\output.png"); // or .pdf, .jpeg, etc.

If you cannot run Word on the server, you can perform this conversion on a workstation and then move the upgraded DOCX to the server for rendering.

  1. Render the document directly with Word automation
    When conversion is not feasible, let Word itself generate the PNG/PDF. This bypasses Aspose.Words for the affected documents and guarantees that the EQ field is rendered as Word displays it.

  2. Check for updates to Aspose.Words
    Periodically review the release notes of newer Aspose.Words versions to see whether native support for legacy EQ fields has been added. If a future release includes this capability, you can remove the conversion step.

  3. Escalate internally
    If native rendering of EQ fields is a critical requirement, raise an internal feature‑request with the Aspose.Words product team. Provide sample documents that contain the { EQ \o(...) } fields and the expected visual output so the team can evaluate the enhancement.

  4. Validate the output
    After conversion (or after using Word automation), open the generated PNG/PDF and verify that each tone mark appears correctly over or under the Bopomofo characters. If any marks are still missing, confirm that the document now contains <m:oMath> elements by inspecting the DOCX XML.

3

Thank you for your response.

I have provided sample files and code to reproduce the issue. Should you require any additional information, please feel free to contact me at your convenience. I appreciate your attention to this matter, and I look forward to your continued correspondence and further updates regarding its resolution.

4

@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-28823

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.