布局保真度
分页、页眉页脚、栏、表格和嵌入图像的布局与 Word 相同，因为输出的是页面图像，而非 HTML 近似。
问题
为何 interop 总是以糟糕收场
Office 自动化是为拥有登录用户的桌面设计的，而不是处理二十个并发请求的服务。在负载下会死锁，弹出对话框却无人能关闭，进程会在请求结束后仍然存活，直至机器耗尽内存。
授权情况同样糟糕：为众多用户渲染文档的服务器需要本不该需要的桌面许可证。
原生渲染规避了所有这些问题。Doconut 打开文件，进行布局，并在进程内生成页面图像。无需安装、监管或授权第二个应用程序。
功能
渲染后保留的内容
完整的 Word 系列
.doc、.docx、.docm、.dot、.dotx、.dotm、.rtf、.odt、.ott 和 .xml 均通过同一调用打开。
您可控制的字体
渲染使用服务器上已安装的字体，因此文档外观取决于您的部署环境，而不是阅读者使用的机器。
隐藏内容保持隐藏
页面图像不包含修订痕迹、已删除文本、批注或作者元数据。发送图像而非 DOCX 能显著降低信息泄漏。
跨文本层搜索
使用 AdvancedSearch 插件，搜索针对文档文本进行，而不是针对其图片。
按需转换
借助 Converter 插件，DocumentConverter.ConvertAsync() 在同一进程中生成 PDF 或其他目标——当需求是归档而非查看时非常有用。
集成
打开 DOCX
注意，.xml 由 Word 渲染器和 WordConfig 处理。它不是通用的 XML 查看器——之所以存在是因为 Word 自身的 XML 格式进入了该管道。
支持的扩展名
.doc.docx.docm.dot.dotx.dotm.rtf.odt.ott.xml
csharp
// Identical to every other format — the family is detected from the document
string token = await viewer.OpenDocumentAsync("wwwroot/files/Agreement.docx");
// With the Converter plugin, when the requirement is a PDF for the archive
await DocumentConverter.ConvertAsync(
"wwwroot/files/Agreement.docx",
"wwwroot/archive/Agreement.pdf");详情
Word 细节
- 整个过程中不涉及 Microsoft Office 安装，也不涉及 COM interop。
- 在渲染主机上安装文档引用的字体；字体替换是导致意外重排的常见原因。
- 转换为 PDF 及其他目标需要 Converter 插件。
常见问题
服务器上需要 Microsoft Office 吗？
不需要。渲染是原生的。没有 Office 安装、没有 interop 程序集，也没有需要监管的自动化进程。
布局会与 Word 显示的相匹配吗？
分页和布局在服务器端复现，只要文档引用的字体已在渲染主机上安装，结果就会非常接近。缺失的字体会被替换，而替换会导致布局变化。
修订痕迹和批注会显示吗？
渲染的页面显示文档的布局，而不是其背后的修订元数据。事实上，这是一项特性——审阅者经常转发包含已删除文本的 DOCX 文件，认为这些文本已消失。