2022 年，我们启动了公式编辑器开发计划，希望为大家打造一款简单、好用，并且能够与 Word 深度兼容的公式编辑器。然而，项目很快遇到了最大的技术难题：OLE 全链路始终无法打通。
OLE 是一项历史悠久、体系复杂的技术。现有资料非常有限，可参考的框架也大多年代久远，开发和接入难度都很高。我们进行了多轮技术攻关，也尝试过许多不同的实现方案，但始终未能达到可以正式交付的标准。为此，我们为所有参与预售的客户办理了退款。
不过，退款并不意味着放弃。
这些年来，我们一直在继续研究和验证，希望真正打通这条技术链路。之所以没有选择更容易的替代方案，是因为如果绕开 OLE，在 Word 中进行公式插入、编辑和回传时，兼容性、性能与稳定性都很难达到我们的要求。尤其是在链路较长、需要频繁转换的场景下，速度和稳定性问题会更加明显。
也有朋友问：为什么不用 MathML 或者微软的 OMML？
作为长期从事文档处理和 IDP 技术研发的从业者，我们在 LaTeX 公式的识别、处理与转换方面积累了较多经验。在实际应用中，MathML 和 OMML 都有各自的价值，但在复杂公式排版、样式控制和深度自定义方面仍然存在一定局限。公式与普通文字之间的粘连、拆分和转换，也一直是比较棘手的问题。
为此，我们在极度公式中专门进行了防粘连处理，尽可能避免将普通文字错误地写入 MathML 结构，从而降低后续编辑和转换过程中出现异常的概率。
相比之下，OLE 的实现难度虽然更高，但在 Word 桌面端的深度集成、对象编辑和自定义能力方面具有明显优势。国内能够完整支持 OLE 公式编辑链路的产品并不多，而这一次，我们终于把它做出来了。
为了攻克这些问题，我们查阅了大量早期资料，其中包括 1992 至 1994 年间出版的相关技术书籍，并对整个 OLE 工作机制进行了重新梳理。最终，我们将传统上主要依赖 C++ 实现的关键链路，在 C# 中完成了封装、实现和闭环测试。
采用 C#，可以更方便地利用 Office 原生的加载项和 Word 面板注册能力，不再依赖宏来实现主要功能。宏方案不仅部署和维护较为复杂，在部分环境中还需要额外安装或启用 VBA 组件，也容易受到安全策略限制。通过使用 C#，我们能够减少直接操作指针和手动管理内存带来的风险，并更好地控制线程、异常处理和资源释放，从而提升整体稳定性与转换效率。
多懒公式目前刚刚发布，仍然有许多需要继续完善的地方。接下来，我们会持续优化公式编辑体验、兼容性、转换速度和稳定性，同时积极推进跨平台版本建设。由于 OLE 主要服务于 Windows 桌面环境，其他平台将通过相应的系统能力和适配方案，实现公式数据在不同设备与应用之间的协作。
从 2022 年到现在，四年时间转瞬即逝。感谢大家一路以来的理解、等待、支持与鼓励。
久等了，也十分感谢。