Great question—this is a common pain point with OpenXML, since it’s a content-focused format (storing text, styles, and structure) rather than a layout-focused one. As you noticed, raw OpenXML doesn’t embed position data for basic text runs because Word calculates layout dynamically based on factors like font, page settings, and rendering environment. Let’s walk through your options:

Why OpenXML SDK Alone Can’t Do This #

OpenXML’s core purpose is to represent document content and structure, not to track rendered positions. The <w:r> (run) elements only contain text and style references—no x/y coordinates, offsets, or layout metadata. The SDK doesn’t include a layout engine to compute these values, so you’ll need additional tools.

Practical Solutions #

1. Use Microsoft Office Interop (Free, but Requires Word Installed) #

If you can run your code on a machine with Microsoft Word installed, Office Interop lets you leverage Word’s built-in layout engine to get precise run positions. Here’s a C# example:

using Microsoft.Office.Interop.Word;

// Initialize Word application
var wordApp = new Application { Visible = false };
var document = wordApp.Documents.Open(@"C:\path\to\your\document.docx");

// Locate your target run (adjust this to match your text or criteria)
var targetText = "Your specific plain text here";
var foundRange = document.Content.Find.Execute(targetText).Range;

// Get position relative to the page (units are points)
float horizontalPos = foundRange.get_Information(WdInformation.wdHorizontalPositionRelativeToPage);
float verticalPos = foundRange.get_Information(WdInformation.wdVerticalPositionRelativeToPage);

// Convert points to pixels (96 DPI is standard; 1 point = 96/72 pixels)
int pixelX = (int)(horizontalPos * 96 / 72);
int pixelY = (int)(verticalPos * 96 / 72);

// Cleanup
document.Close(SaveChanges: false);
wordApp.Quit();

Note: Interop isn’t ideal for server environments (it requires Word to be installed and has stability/performance limitations), but it’s the easiest free option for desktop use.

2. Use a Third-Party Library (Server-Friendly, Some Paid) #

If you need to run this without Word installed (e.g., on a web server), libraries like Aspose.Words (commercial) include built-in layout engines that can compute run positions accurately. Here’s an example:

using Aspose.Words;
using Aspose.Words.Layout;

var document = new Document(@"C:\path\to\your\document.docx");
var layoutCollector = new LayoutCollector(document);
var layoutEnumerator = new LayoutEnumerator(document);

foreach (Run run in document.GetChildNodes(NodeType.Run, true))
{
    if (run.Text.Equals("Your target text", StringComparison.Ordinal))
    {
        // Map the run to its layout entity
        var layoutEntity = layoutCollector.GetEntity(run);
        layoutEnumerator.Current = layoutEntity;

        // Get the bounding rectangle (points) and convert to pixels
        var rect = layoutEnumerator.Rectangle;
        int pixelX = (int)(rect.X * 96 / 72);
        int pixelY = (int)(rect.Y * 96 / 72);
        
        break;
    }
}

Aspose.Words has a free trial and handles most Word layout edge cases (line breaks, pagination, styles) reliably. For open-source alternatives, check out OpenXML PowerTools—it has limited layout-related utilities, but may cover basic use cases.

3. Roll Your Own Layout Engine (Not Recommended) #

You could technically implement Word’s layout rules from scratch (calculating font metrics, line spacing, paragraph margins, etc.), but this is an enormous undertaking. Word’s layout logic is incredibly complex, and even small edge cases (like hyphenation, different font sizes, or page breaks) would require thousands of lines of code. This is rarely worth the effort.

Final Takeaway #

You can’t get run coordinates directly via the OpenXML SDK alone, but you have solid workarounds:

• Use Office Interop if Word is available on your runtime environment.
• Use a third-party library for server-side or headless scenarios.

内容的提问来源于stack exchange，提问作者Proko