LaTeX公式如何进入Word？OMML转换链路与Pandoc实践

写过论文的人，基本都经历过这种时刻：LaTeX 里一条含分数、根号、积分上下限的公式十秒写完，导师却要求“最后交 Word 版”；或者你在 Word 里补公式，MathType 突然卡死，光标在文档里转了好几圈；更常见的是，从 Word 复制一条公式到 WPS，对方看到的却是一个灰色方块。三种软件来回切换，半天过去，文档里只多了一行字。

最近有读者问到一个很具体的问题：GenOffice 能在 Word 里写 LaTeX 公式吗？顺手还要和 WPS 对比一下。之所以会有这样的问题，是因为越来越多办公套件开始宣传“支持公式”“兼容 Office”，谁看了都会动心。但这里我要先说一个判断：与其追问“哪个软件支持 LaTeX 语法”，不如先看清 Word、WPS、GenOffice 底层那条公式链路。真正决定体验的，从来不是工具栏里有没有几个 LaTeX 按钮，而是 LaTeX、MathML、OMML 这三种格式之间能不能平滑转换，以及在文档里最终落地成哪种对象。

这篇文章会讲清楚三件事。第一，Word 里的公式对象到底有哪几种形态，为什么这个差异直接决定了工具好不好用；第二，给你一套不看广告看实效的判断维度，用来检查 GenOffice 和 WPS 在公式场景下的真实水平；第三，给出四条不依赖特定软件也能把 LaTeX 公式搬进 Word/WPS 的通用路径，附带可直接复制的命令和代码。读完你会得到一个结论：办公软件负责的是终稿呈现，LaTeX 语法本身才是应该留在你源文件里的东西。

1. 你的痛点不是“公式编辑器”，而是“文档格式链路”

先还原几个真实的使用场景，你会发现大家吐槽的方向其实很一致。

理工科研究生的典型困境是：论文正文在 LaTeX 里写，公式排得干干净净，但导师需要在 Word 里批注，期刊返修系统也只接受 Word 文档。于是你得把整篇论文从 LaTeX 转成 Word。公式一旦多起来，转换结果总会出现几个裂缝：有的变成图片，有的丢失上下标，有的干脆显示成乱码。此时你没有心情去研究“哪个工具更好”，你只想知道“怎么才能让公式安安稳稳到 Word 里”。

期刊投稿和出版社返修则是另一个场景。编辑部给的 Word 模板锁定了字体和样式，你必须把公式一条条粘进模板。如果你用 MathType，版本不匹配时复制公式到 Word 会卡顿甚至崩溃；如果你直接粘贴 LaTeX 源码，Word 根本不会解析它，只会当成一行普通文本。你会发现，问题不在键盘上，而在格式转换这条链路上。

还有一类工程师，不需要写论文，但要写带数学推导的详细设计说明书。他们的痛点是跨软件协作：同事用 WPS 打开你做的 Word 文档，公式变成灰色块；你用 WPS 打开同事的 Word 文档，公式又变成图片。反复沟通后大家只能约定“公式用截图”，但截图公式不可编辑、不可搜索、不可版本管理，属于最差实践。

把这些场景放在一起看，结论就很清晰了：真正的痛点是文档格式链路，而不是某一次“插入公式”的动作。LaTeX 的优势是公式用文本描述，方便 Git 管理和批量替换；Word 的公式却是结构化树形对象，它在磁盘上是一段 XML。两条生态之间的桥，才是大家真正需要的。所以，谁能把“LaTeX 公式文本”转换成“Word 原生公式对象”这件事做顺畅，谁才是真正解决了问题。

2. 基础概念：Word 公式的四种形态与 LaTeX 语法

2.1 Word 里的公式到底有哪几种形态

在讨论“支持不支持”之前，必须先建立一套判断坐标系。在 Word 生态里，公式至少有四种完全不同的存在形态，可编辑性天差地别。

先说图片公式，这是最差的形态。图片公式在任何软件里都能显示，但它不可编辑、不可搜索、不能被公式编号工具识别。论文反修时你没法修改图片里的一个字母，只能重做整张图。

线性文本公式更接近“可编程”的状态。Word 的公式编辑器支持一种线性语法，输入 \int_0^1 x^2 dx 后，Word 会把它解析成图形化的公式。这种文本形态的好处是容易被脚本生成和修改，但它是“输入层”，不是最终存储形态。

OMML 原生公式才是 Word 的“母语”。它是 OOXML 标准的一部分，以 XML 节点的形式存放在 word/document.xml 中。双击公式可以进入编辑状态，公式工具选项卡会出现，上下标、根号、分数都是可选中、可修改的结构。我们要想做到“在 Word 里用 LaTeX 的思维写公式”，最终目标就是生成这种对象。

OLE / 域公式主要由 MathType 这类第三方工具产生。它本质上是在文档里嵌入了一个外部对象，双击时调用 MathType 来编辑。一旦软件环境变化，这类公式很容易变成灰色块或无法打开。在“Word 里写 LaTeX”这件事上，OLE 并不是一个值得依赖的最终形态，它更像历史包袱。

2.2 LaTeX 公式语法为什么让人上瘾

LaTeX 语法本质上是“用文本描述公式的结构”。一段给论文用的积分公式，在 LaTeX 里写下来是这样：

latex复制\begin{equation}
  \int_{0}^{1} \frac{x^2}{\sqrt{1+x^2}} \, dx
  = \frac{\sqrt{2} - \ln(\sqrt{2}+1)}{2}
\end{equation}

这段文字放进任何一个文本编辑器都可以编辑、可以进 Git、可以用脚本批量替换。而且 LaTeX 把“分数的分子分母”“根号内容”“积分上下限”这些结构用 \frac{}{}、\sqrt{}、\int_{}^{} 描述得清清楚楚。这是它比鼠标点选高效的核心原因。

反观 Word 的 OMML，同样是这个公式，在底层 XML 里却是一棵复杂的树，包含分数结构、上下标结构、根号结构。如果直接改写 XML，光是维护命名空间和节点嵌套就够写一大堆代码。所以你从 LaTeX 源码复制一段文字直接粘贴到 Word，Word 大概率把它当成普通文本，因为它不认识任意 LaTeX 命令。

最朴素的理解方式是这样：LaTeX 是在“告诉编译器我想画什么”，Word 公式是在“保存一棵结构树”。两者之间必须经过一个“解析并重新组织”的步骤，这正是转换工具的用武之地。

2.3 被很多人忽略的 Word 原生线性公式

说到这里，你可能会问：那 Word 有没有自己的“类 LaTeX 文本输入”能力？其实是有的，只是很多人在 Word 里写公式永远是鼠标点选，从未尝试过键盘流。

在 Word 中按 Alt + = 可以调出公式框，然后输入线性文本。比如输入：

code复制\int_0^1 x^2 dx

输入过程中按空格或 Tab，Word 会尝试把它渲染成专业公式。\frac{1}{2}、\sqrt{x}、\sum_{i=1}^{n} 这些命令在 Word 的线性语法中同样有效，看起来和 LaTeX 几乎一样。

但注意，这里有个容易踩坑的地方：Word 的线性公式语法是 UnicodeMath，它只是“长得很像 LaTeX”，不是完整的 LaTeX。\frac、\int、\sqrt 这些常用命令没问题，但 \operatorname、\bm、\mathbf 这类命令支持有限，遇到复杂宏定义时经常会解析失败。所以，当营销文案说“支持 LaTeX 公式”时，要问清楚：是支持常用命令，还是支持完整语法？绝大多数办公套件只做到了前者。

3. GenOffice 能行吗：三个维度替你把把关

先说明一个边界：我并没有逐版本替 GenOffice 做公式功能实测，因为办公套件的公式能力往往随版本而变化，而不同发行版的差异也很大。所以在这一节里，我更想给你一套可以自己执行的检查框架。你拿到手里的 GenOffice 版本之后，花五分钟就能判断它到底能不能满足“在 Word 里写 LaTeX 公式”的需求。

3.1 维度一：文件格式兼容能否正确读写 OMML

第一步，不看宣传，直接用文件说话。找一个包含大量 OMML 原生公式的 docx 文档，在 GenOffice 里打开。然后逐个公式尝试点击、进入编辑态、修改一个字符、保存。最后再用 Microsoft Word 打开这个保存后的文件，检查公式是否仍然是可以编辑的 OMML 对象，而不是变成图片或抹掉的灰块。

这个测试之所以是第一步，是因为“能显示公式”和“能编辑公式”是两件不同的事。许多兼容型办公套件为了控制成本，会在“显示公式”上做足功夫，但当你试图双击编辑时，它只提供一个“转为图片”的选项，甚至直接弹窗告诉你功能未支持。公式兼容看起来只是 Office 兼容的一个子集，但恰恰是容易被砍掉的那一块。

如果 GenOffice 能原样读写 OMML，那它可以作为公式的“接收方”进入你的工作流。你可以先在 Word 或转换工具里生成公式，再到 GenOffice 里完成终稿排版。但要注意，这只是及格线，不是卖点。

3.2 维度二：公式输入与编辑是否支持线性语法

第二步，测试公式输入路径。打开 GenOffice 的公式编辑器，看看它是“符号面板 + 模板点选”模式，还是支持键盘输入线性语法。建议做一个三连测试：

1. 在公式框里输入 \frac{1}{2}，按空格，看是否出现分数结构。
2. 输入 \sum_{i=1}^{n}，看是否出现求和符号及上下标。
3. 输入 \sqrt[3]{x}，看是否出现带可选次数的根号。

如果三个都成功，说明 GenOffice 的公式编辑器至少具备类 LaTeX 的线性输入能力，日常补充公式够用。如果只有符号面板，那你没法在 GenOffice 里“写” LaTeX，只能从外部粘贴。

这里还要补充一个容易误判的点：很多办公套件所谓的“LaTeX 支持”，其实是符号映射表，它认识 \alpha、\beta、\infty 这类单个符号命令，但不认识 \frac、\sqrt、\int 这种结构命令。结构识别能力，才是判断“类 LaTeX 输入”的关键指标。

3.3 维度三：自动化扩展能力能否进入论文工作流

第三个维度，看它是否给开发者留了后门。批量插入公式、自动编号、交叉引用更新，这些论文写作中早晚会遇到的操作，都依赖宏或脚本能力。如果 GenOffice 支持 VBA 或 JavaScript 宏，那你至少可以通过脚本批量注入 OMML 公式；如果完全没有扩展 API，它就只能停留在“单条公式编辑”的层面。

从办公套件行业的一般规律来看，完整保留 VBA 兼容并不容易，因为 VBA 是一个庞大的运行时环境，即使看起来兼容，也会在各种边缘行为上出现差异。更务实的期待是 JavaScript 宏，它实现成本低，生态也在快速补齐。如果你需要在文档流水线里自动化处理公式，这一点必须先确认。

小结论：GenOffice 能不能行，本质上取决于它是否把 OMML 的读写做完整、公式编辑器的线性输入能做到什么程度、以及是否留有自动化通道。把它当作“接收 OMML 公式并完成终稿排版”的工具，是更稳妥的定位；指望它内置一个完整的 LaTeX 解析器，大概率会失望。

4. 顺手对比 WPS：它离“Word 里写 LaTeX”还有多远

把 WPS 放进同一套判断框架里看，会更有坐标感，因为 WPS 是许多人在“不想用 Word 时”的第一选择。

4.1 WPS 的公式输入路径

WPS 内置了公式编辑器，插入入口是“插入 → 公式”，也可以按快捷键进入公式编辑状态。它的线性输入模式对 \frac、\int、\sum 这类常用命令支持得比较自然，输入后按空格即可渲染成公式。从体感上说，WPS 是“Office 兼容班”里最接近 Word 使用习惯的办公套件之一，至少不是纯符号面板点选。

但这里有一个容易被放大的错觉：WPS 支持若干 LaTeX 风格命令，不代表它支持 LaTeX 语言。你要在 WPS 里写 \operatorname*{arg\,max} 这种带限制条件的结构，可能需要绕路到“函数”模板里手动调整。所以把 WPS 当“能听懂部分 LaTeX 的工具”可以，当“LaTeX 编译器”则不行。

4.2 WPS 与 OMML 公式的互操作

互操作测试很直观：从 Word 复制一个含复杂公式的 docx 到 WPS，通常能显示，点击后也能进入编辑。复杂公式的字体、间距可能出现轻微变化，但只要不涉及特别奇怪的宏包结构，基本可用。反过来，WPS 生成的公式如果导出成 docx，Word 能否识别，取决于 WPS 是否把它存储成 OMML。只要你在 WPS 里用的是自带公式编辑器生成的公式对象，导出后一般就是 OMML，Word 能正常编辑。

真正要警惕的是“公式导出成图片”的默认行为。某些办公套件为了兼容性，会在另存为时把不可识别的公式对象降级成图片。跨软件协作时的正确打开方式是：在 Word 里用“另存为”保留 OMML，在 WPS 里也选择兼容 OOXML 的格式，并且双方都用 Office Open XML 作为交换格式，而不是互相导出 PDF 或图片再粘贴。

4.3 MathType 与 WPS 的老问题

很多读者问过“MathType 如何嵌入 WPS”“MathType 复制到 Word 卡死”，这两个问题实际上是同一个底层矛盾的两种表现：MathType 的插件体系主要围绕 Microsoft Word 的 COM 接口设计，WPS 的插件接口和宏模型虽然越来越接近 Word，但毕竟不完全一致。MathType 在 WPS 里通常只能以“插入对象”的方式工作，双击后打开 MathType 窗口编辑，自动化程度远不如 Word 里那么原生。

至于“MathType 复制到 Word 卡死”，常见原因是 MathType 版本和 Word 版本不匹配，或者 MathType 插件与 Word 的其他加载项冲突。这类问题不是 Word 或 LaTeX 本身造成的，而是闭源插件在版本矩阵里出了岔子。我的建议是：如果你已经能用 OMML 公式解决问题，就不要重新引入一个比 OMML 还要重的第三方 OLE 工具。

把 Word、WPS、GenOffice 放在一起看，它们的定位差异会非常清晰。

所以，WPS 在 Office 兼容班里已经是公式能力较强的选手，但它真正的强项是轻量办公，不是数学排版。如果你在 WPS 和 Word 之间反复切换交付论文，建议先统一公式格式为 OMML 对象，再讨论其他排版细节。

5. 不依赖特定软件的通用方案：LaTeX → OMML → Word/WPS

无论 GenOffice 还是 WPS 的公式能力如何，都不能改变一条底层事实：LaTeX 公式文本必须经过转换才能变成 OMML 对象。与其在每个办公软件里找残缺的“LaTeX 支持”，不如掌握一条稳固的通路。下面是四条我从工程角度推荐的路径，按外部转换和内部生成分组。

5.1 方案一：用 Pandoc 把 LaTeX 文档转成 docx

Pandoc 是文本格式转换领域的事实标准，它能把 LaTeX 数学环境转换成 Word 原生 OMML 公式。你不需要先写好整篇论文，哪怕只是一个公式片段，只要写成一个最小 .tex 文件，Pandoc 也能生成可编辑公式的 docx。

假设你有一个文件 formula.tex，内容是：

latex复制\documentclass{article}
\begin{document}
行内公式 \( a^2 + b^2 = c^2 \)。

行间公式:
\[
  \int_{0}^{1} \frac{x^2}{\sqrt{1+x^2}} \, dx
  = \frac{\sqrt{2} - \ln(\sqrt{2}+1)}{2}
\]
\end{document}

然后在终端执行：

bash复制pandoc formula.tex -o formula.docx

打开生成的 formula.docx，两条公式都是可以点击编辑的 OMML 对象，不是图片，不是纯文本。

Pandoc 的转换之所以可靠，是因为它内部用的是 texmath 这个数学公式转换库，而不是简单做字符串匹配。texmath 会把 LaTeX 公式解析成内部数学表达式树，再根据目标格式序列化。也就是说，它是真的“看懂”了 \frac、\sqrt、\int 这些结构，再重新组织成 OMML。

但有两个坑需要提前知道。第一，Pandoc 解决的是公式本体，表格、交叉引用、图片位置在转换后需要手动调整。第二，LaTeX 里自定义的宏包和 \newcommand 支持有限，转换前先备份 .tex 源文件，遇到“公式格式崩了”就回滚改命令再转。

5.2 方案二：LaTeX → MathML → 剪贴板粘贴

如果你不想安装命令行工具，可以使用“LaTeX 转 MathML”的方式。MathML 是数学标记语言，许多办公软件对 MathML 剪贴板有识别能力。Python 生态里有一个轻量库叫 latex2mathml，可以把 LaTeX 公式文本转成 MathML。

先安装：

bash复制pip install latex2mathml

然后运行：

python复制import latex2mathml.converter

latex_code = r"\int_{0}^{1} \frac{x^2}{\sqrt{1+x^2}} dx"
mathml = latex2mathml.converter.convert(latex_code)
print(mathml)

终端会输出一段带 math 根的 XML。把这段 MathML 文本复制到剪贴板，在 Word/WPS 里执行“选择性粘贴”。如果目标软件的剪贴板识别完整，公式会作为可编辑公式对象插入；如果识别不了，你就退回到方案一，用 Pandoc 生成 docx 再复制。

这个方案适合“偶尔插入一两条公式”的场景，不依赖办公软件的品牌或版本，代码也很短。但它同样不是万能的，遇到复杂的矩阵、多行对齐公式时，latex2mathml 的输出可能不够细致，需要人工检查。

5.3 方案三：在 Word 内直接用 VBA 生成公式对象

如果你已经在 Word 里，不想调用任何外部工具，可以用 VBA 直接创建公式对象。Word 的 API 允许你在光标位置添加一个 OMath 对象，然后给它喂线性语法文本，Word 会自行解析并渲染。

下面是一个可以直接粘贴到 VBA 编辑器里的最小示例：

vba复制Sub InsertLatexLikeFormula()
    Dim oMath As OMath
    ' 在当前光标位置新建公式对象
    Set oMath = Selection.OMaths.Add(Selection.Range)
    ' 写入类 LaTeX 的线性语法，Word 自动解析为公式
    oMath.Range.Text = "\int_0^1 \frac{x^2}{\sqrt{1+x^2}} dx"
End Sub

使用方法：在 Word 里按 Alt + F11 打开 VBA 编辑器，插入一个模块，把代码粘贴进去，然后关闭编辑器回到文档，把光标放在要插入公式的位置，按 Alt + F8 运行这个宏。

这里的原理是：OMaths.Add 创建的是一个空公式对象，而公式对象的 Range.Text 属性接受 UnicodeMath 线性语法。\int、\frac、\sqrt 在 UnicodeMath 里都有对应结构，所以这段文本能被正确解析。

但注意，前面已经反复强调过：不是所有 LaTeX 命令都被 UnicodeMath 支持。如果宏运行后公式区域出现奇怪的符号组合，说明练习文本里包含不支持的命令，需要换成 Word 公式工具栏里存在的结构。宏是代码，建议只在可信文档中运行，并且先检查代码内容再启用宏。

5.4 方案四：python-docx 批量注入 OMML 的思路

最后一个方案面向开发场景：当你有几十条公式需要批量注入 docx，且不能打开 Word 自动化时，可以用 python-docx 直接操作 OOXML。python-docx 本身不提供公式对象 API，但 OMML 本质是 XML 节点，我们可以手动把它挂到段落上。

下面是一个思路级示例，向段落追加一个最简公式对象 x+1：

python复制from docx import Document
from docx.oxml import parse_xml
from docx.oxml.ns import nsdecls

doc = Document('template.docx')
p = doc.add_paragraph()

# 极简 OMML 片段，只演示节点的插入方式
omml = (
    f'<m:oMath {nsdecls("m")}>'
    f'<m:r><m:t>x</m:t></m:r>'
    f'<m:r><m:t>+1</m:t></m:r>'
    f'</m:oMath>'
)
p._p.append(parse_xml(omml))

doc.save('output.docx')

这段代码能把 x+1 作为公式对象写入段落，但离真正可用的公式注入还差得远。真实场景里，你需要先把 LaTeX 转成 OMML XML，再处理 m:sSup、m:f、m:rad 这些结构节点，还要保证命名空间正确。个人用户我建议直接用方案一，方案四更适合要写内部工具团队的参考方向。

四条路径的选择逻辑很简单：

• 整篇论文交付：选 Pandoc。
• 只需补几条公式：用 MathML 方式或方案三 VBA。
• 要写自动化流水线：研究方案四，但先跑通方案一再封装。

6. 如何验证公式是“真可编辑”而不是“假图片”

转换完成后，必须做验证。很多同学打开转换出来的 docx，看公式“长得很正常”就以为成功了，但过两天在 Word 里想修改一个上标才发现公式是图片，回到原点。

第一个检查点：点击公式，看看功能区是否出现“公式工具”上下文选项卡。如果只是普通的图片格式，选中后会显示“图片工具”或只有大小调整手柄，不会有公式结构编辑按钮。

第二个检查点：双击公式，能不能进入编辑状态，光标能不能点在公式内部并选中某个元素。真 OMML 公式可以在公式内部用光标选择分子、下标、根号内容，图片公式做不到。

第三个检查点：在公式上右键，看菜单里有没有“转换为线性显示”或“转换为 UnicodeMath”选项。这是 Word 原生公式对象特有的能力，图片和 OLE 对象都没有。

还有一个快速识别法：复制公式，然后粘贴到记事本。如果粘贴出来的内容是一段 XML 或者线性文本，说明它是公式对象，因为剪贴板里传输的是公式结构；如果粘贴出来是一张图片或空白，说明它是图片/OLE。这个测试在 WPS 里同样适用，区别只是 WPS 对剪贴板内容的表述不同。

跨软件测试也很重要。把公式 docx 在 Word 里编辑一次，保存，再到 WPS 里打开、编辑、保存，最后用 Word 打开最终文件。如果公式仍然是可编辑对象，兼容性才算过关。任何一步把公式降级成图片，都要回到转换流程里找原因。

7. 常见问题与排查思路

挑两个最常见的展开说。

“公式粘贴后变成图片”这个问题，根源几乎都在剪贴板格式。Word 的剪贴板可以同时携带多种格式：纯文本、RTF、HTML、图片、OMML。当你从网页或 PDF 复制公式时，目标软件可能只拿到了图片格式，于是只能粘贴成图。验证方法就是在问题发生前先做一次“粘贴到记事本”测试，确认剪贴板上有没有公式的文本/XML 层。

“Word 公式在 WPS 中变灰”的问题，则要分清楚是显示问题还是数据问题。如果 WPS 能显示公式但点击无效，说明它没有把 OMML 完整解析成公式对象，只是做了静态渲染；如果保存后再用 Word 打开发现公式被破坏了，那就更危险。遇到这种情况，不要再让 WPS 作为主要编辑器，把公式编辑工作留在 Word 里完成，WPS 主要看版式。

8. 最佳实践：论文写作的公式工作流建议

结合前面的分析，我建议在论文写作或者技术文档工作中，坚持几条原则。

第一，公式的“源文件”永远是文本。LaTeX 源码可以进 Git，可以做 diff，可以在不同工具间反复使用。Word 里的 OMML 公式对象是最终产物，不是源文件。你可以在 Word 里编辑它，但不要把唯一版本只保存在 Word 里。每次从 LaTeX 转 Word 之后，建议把 .tex 文件保留在项目目录里，需要反悔时重新转换，而不是在 Word 里手工修补。

第二，跨办公套件协作时，公式一律走 OMML 对象，不要用图片。图片公式虽然保证在任何软件中都能显示，但也意味着不可编辑、不可搜索、不可编号。约定“公式不截图”这条纪律，比讨论“哪个软件支持 LaTeX”更重要。

第三，投稿或者提交模板之前，先确认目标期刊或学校到底要什么。有的系统要求 docx，有的直接收 LaTeX 就没必要转 Word；有的只收 PDF 终稿，那中间环节都可以自由选择。不要为了“看起来兼容”而浪费时间做格式转换。

第四，使用 Pandoc 做批量转换时，先拿一两页做实验，再转换全文。pandoc paper.tex -o paper.docx 这行命令看似简单，但复杂文档经常会出现表格错位、图片引用丢失、公式编号丢失等问题。先转换小样本，确认公式和图片都正常，再处理完整文档，能节省大量返工时间。

第五，安全问题要给足重视。宏可以批量插入公式，但也可能是恶意代码，只运行来源可信的宏脚本。MathType 和老版本 Word 的插件冲突已经够烦了，所谓“破解版 MathType 或 WPS”通常会引入更多不确定行为，建议一律不用。

第六，公式编号尽量在 Word 里用题注体系完成。Pandoc 不会帮你重建 LaTeX 的 \label 和 \ref，转出来的 docx 里没有公式编号。转换后要及时建立“第几章—公式序号”的编号规则，这样后续插入新公式时编号会自动更新，不会出现“公式 5.3”和“公式 5.4”之间忘了插一条导致全部重编的窘境。

9. 总结与后续学习方向

回到最初的问题：GenOffice 能在 Word 里写 LaTeX 公式吗？顺手和 WPS 对比，到底该选哪个？

我的判断是：不要把希望寄托在某个办公软件内置了一个完整 LaTeX 引擎上。办公套件的定位是“展示和编辑文档”，不是“解析 LaTeX 语言”。GenOffice 能不能行，看两件事就够了：一是它能否完整读写 OMML 公式对象，二是它是否支持线性公式输入的常用结构命令。WPS 比很多兼容型套件更接近用户习惯，在 \frac、\int、\sum 这层命令上做得相对顺手，但它同样不是 LaTeX 环境，复杂公式一样需要回到转换链路里解决。

真正值钱的技能，是掌握 LaTeX → MathML → OMML 这条转换链路。Pandoc 帮你解决整篇转换，latex2mathml 帮你做单条公式的轻量转换，Word 的 VBA 可以处理临时插入，python-docx 则适合批量注入。无论你手里是 Word、WPS 还是 GenOffice，只要这条链路是通的，公式就能以可编辑对象的形式抵达最终文档。

后续如果想继续深入，可以按这个顺序学习：先读一遍 Pandoc 的用户手册里关于数学公式渲染的章节，理解转换边界；再搜“UnicodeMath 线性格式”文档，搞清楚 Word 公式原生支持哪些结构命令；最后了解 OMML 的基本 XML 结构，知道它存储在 word/document.xml 里即可。如果你想写自动化工具，latex2mathml 和 texmath 这两个库是很好的起点。

做完这篇文章里的四个方案之后，建议找一个至少包含二十条公式的论文，分别用 Pandoc 和 VBA 方案试一遍，把失败的公式命令记下来。这张失败清单，才是你真正需要维护的公式迁移边界。