简介一套基于纯Java编写的FrameMaker模板引擎示例代码面向需要了解模板引擎工作原理、FTL模板与Java代码配合方式的Java开发者。资源通过两个典型入口演示核心用法com.SimpleFTL.java配合template/simpleFTL.ftl执行main函数在控制台输出结果com.FTL1Servlet.java配合template/ftl1.html通过浏览器访问Servlet查看渲染效果适合作为模板引擎入门或二次开发参考。压缩包共24个文件大小仅13KB包含java、ftl、html、xml、class等类型以及Eclipse工程配置.classpath、.project和Maven构建文件pom.xml目录结构清晰便于直接导入工程运行调试。目前已有553人浏览学习对快速掌握模板引擎输出流程、Servlet集成方式及FTL语法具有实用参考价值。 第一次把 FrameMaker 的脚本从别人手里接过来时我在电脑前坐了一整天连一个段落属性都没改成功。后来我把 MIF、ExtendScript、FDK 这三条路都摸了一遍才算弄明白这套长文档工具到底是怎么让人扩展的。这篇内容就是基于我自己的实操经验用几个能直接跑的实例代码带你把 frameMaker 的自动化玩法从头到尾理一遍。如果你是刚接触 FrameMaker 的文档工程师、DITA 技术编辑或者只是想批量处理十几个 .fm 文件的脚本爱好者这篇文章应该适合你。不需要太深的编程基础但至少要懂一点 XML、JavaScript 或者命令行操作。实例代码我会尽量写得完整也会解释每段代码在干什么、为什么这么写这样你拿过去改一改就能用在自己的项目上。1. 先搞清楚 FrameMaker 自动化的三条路线1.1 为什么要写代码三种方案横向对比很多人第一次接触 FrameMaker 自动化是因为遇到了同样的问题文档几千页里面上百个表格光调整列宽和统一编号就能耗掉一整天。FrameMaker 的图形界面做得再顺手也架不住批量重复劳动。这时候就得靠代码。目前实际操作中能走的路线大致有三条MIF 文件FrameMaker 的交换格式可以理解为“给 FrameMaker 看的源代码”。一个 .fm 文档可以另存为 .mif 文本文件你也可以直接手写或由程序生成一个 .mif 文件再让 FrameMaker 打开。MIF 的学习曲线最平缓适合生成新文档、批量替换文本、调整简单格式。ExtendScriptFrameMaker 2019 以后内置的 JavaScript 方言。它可以直接操作当前打开的文档对象模型适合在 FrameMaker 内部做交互式自动化比如遍历段落、改表格、更新交叉引用。FDKC/C 级别的开发套件功能最完整但编译、部署和维护都很重。除非你要做商业插件或者需要深度定制 FrameMaker 底层行为否则不建议碰。我整理了一个简单的对比方案上手难度适用场景典型耗时MIF低批量生成文档、文本替换、格式统一半天到一天ExtendScript中操作当前文档、交互式批量处理一天到两天FDK高商业插件、底层扩展一星期起步1.2 我推荐的路线先学 MIF再学 ExtendScript如果你跟我一样是半路出家做文档自动化我建议你先从 MIF 入手。原因是它足够直观打开一个 .mif 文件你能看到段落、字符串、表格结构都是文本化的哪里不对可以直接改反复打开验证也不怕把文档搞坏。等熟悉了 FrameMaker 文档的底层结构之后再切到 ExtendScript 去写当前文档的操作脚本你会发现很多东西都是相通的。我见过不少人一上来就抱着 FDK 文档啃结果被一堆 C/C 接口绕晕最后啥也没做出来。其实 80% 的日常需求用 MIF 加 ExtendScript 就够了剩下的再考虑 FDK 也不迟。2. 实例一用 MIF 代码直接拼出一个文档骨架2.1 MIF 文件的最小可用示例一个段落就是全部MIF 文件是纯文本格式结构看起来有点像 Lisp 和 XML 的结合体。每一对标签 ... 构成一个对象缩进只是为了方便阅读不是语法要求。下面这个最小示例就是一个带“标题”和“正文”两个段落的文档MIFFile 9.00 # 定义默认字体避免中文字体不一致 DefaultFont FPFamily 宋体 FPSize 10.5pt # 标题段落 Para PgfTag Title PgfNumString 1 ParaLine String 用 MIF 写出的第一个文档 # 正文段落 Para PgfTag Body ParaLine String 这是一个由 MIF 代码生成的正文段落。 把上面的内容保存为hello.mif然后在 FrameMaker 里执行 File Open选择这个文件就能直接打开一个包含两个段落的文档。这里的PgfTag对应文档中的段落标签比如“Title”“Body”String就是段落里的文字内容。需要注意中文字符串要确保文件保存为 UTF-8 with BOM否则打开容易乱码。2.2 用 MIF 生成表格比界面操作更稳的批量方案如果你只是创建几个段落手动操作也不慢。真正体现出 MIF 优势的场景是做批量表格。手工在 FrameMaker 里插入 50 个表格再一个个改列宽、填表头非常折磨人。用 MIF 生成的话只需要循环输出一段结构就行。MIF 表格的基本结构大致是这样的Tbl TblTag Table TblH TblColumns TblColumn TblColumnNum 1 TblColumnWidth 2.0 in TblColumn TblColumnNum 2 TblColumnWidth 3.0 in TblBody TblRow TblCell Para PgfTag Body ParaLine String 列1标题 TblCell Para PgfTag Body ParaLine String 列2标题 实际用的时候我通常会在脚本里定义一个生成表格行的函数循环传入数据拼出一个大字符串再写入 .mif 文件。这样做的好处是数据源和格式逻辑分离数据在 Excel 或 CSV 里维护脚本只负责格式转换改样式的时候也不会影响源数据。值得提醒的是MIF 里单元格中的字符串如果包含特殊字符比如换行、尖括号、引号需要做转义处理否则 FrameMaker 打开时会报错甚至直接打不开文件。这个坑我踩过好几次后来写了一个escapeMifString()函数统一处理所有字符串内容。3. 实例二用 ExtendScript 操作 FrameMaker 对象模型3.1 第一个脚本给所有标题段加上序号前缀FrameMaker 2019 之后内置了 ExtendScript你可以打开脚本编辑器直接写 JavaScript 操作当前文档。下面这个脚本的思路是遍历当前文档主文字流里的所有段落找到段落标签为“Title”的段落然后在段落文本前面加上编号。// 获取当前活动文档 var doc app.ActiveDoc; if (!doc) { alert(请先打开一个 FrameMaker 文档); } else { // 获取主文字流 var flow doc.MainFlowInDoc; var textRange flow.TextRange; // 按场景需要这里用伪代码示意遍历思路 // 具体 API 名称请以你本地的 FrameMaker SDK Doc 为准 var paragraphs textRange.Paragraphs; var counter 0; for (var i 0; i paragraphs.length; i) { var p paragraphs[i]; if (p.Tag Title) { counter; p.TextRange.Text counter . p.TextRange.Text; } } alert(共处理 counter 个标题段); }这个脚本本身逻辑很简单但它背后有一个很重要的理解FrameMaker 的文档对象模型是按“文档—文字流—段落—文字范围”一层层嵌套的。你只要拿到textRange就能通过它的属性和方法遍历、修改文档里的几乎任何内容。在实际项目中我不会直接修改原文而是先复制一份文档在副本上执行脚本确认输出没问题后再应用回原文档。你可以用脚本先生成一个临时文件或者操作时做一次 Undo 备份。3.2 第二个脚本批量修改表格列宽并更新交叉引用处理表格列宽是另一个高频需求。比如你有一个文档里面所有表格的第三列都太宽了想要统一改成 1.5 英寸。手工操作很痛苦用 ExtendScript 就快得多。思路是遍历文档中的所有表格找到每个表格的第三列修改列宽属性。大致代码如下var doc app.ActiveDoc; if (!doc) return; var allTables doc.AllTables; // 按 SDK 实际接口调整 for (var i 0; i allTables.length; i) { var tbl allTables[i]; if (tbl.Columns.length 3) { tbl.Columns[2].Width 1.5 in; } } // 批量更新交叉引用和页码 doc.UpdateReferences();这里最关键的并不是改列宽那行代码而是最后的UpdateReferences()。FrameMaker 的交叉引用、目录、页码编号这些内容在很多情况下并不会实时刷新。脚本改了内容后如果不主动触发更新打开文档时看到的还是旧页码这个问题很容易被忽略。另外遍历表格的时候要注意有些表格是嵌套在单元格里的AllTables拿到的可能只是顶层表格需要递归遍历才能全部覆盖。如果文档结构比较复杂建议先确认表格层级再写遍历逻辑。4. 实例三结构化文档的 EDD 定制4.1 EDD 的基本结构它是怎么约束文档的FrameMaker 除了“未结构化”的普通文档还有一种“结构化”模式常用于 DITA、S1000D 这类规范文档。在结构化模式下文档的内容由元素组成元素的规则由 EDDElement Definition Document来定义。可以简单理解成 EDD 就是一套“文档类型定义”它和 XML Schema 的作用类似但多了排版格式的描述。一个最简单的 EDD 片段如下Element (Container: Section General rule: Section : Title Para Attribute: ID: String ) Element (Container: Title General rule: Title : TEXT Text format rules Font Family: Arial Size: 14pt ) )它表示一个Section元素里包含一个Title和至少一个ParaTitle是文本内容字体为 Arial 14pt。真正用的时候EDD 里的规则会写得很细包括段落间距、自动编号、跨页控制等。EDD 文件本身也可以用文本编辑器打开和修改改完后在 FrameMaker 中导入即可。每次改动 EDDFrameMaker 会重新校验所有文档如果有不合规则的内容会提示你处理。这既是好事也是坏事好处是能强制文档结构统一坏处是存量文档如果本身就不规范导入 EDD 时会有一堆报错。4.2 一个 EDD 实例让每个段落自动带编号很多技术文档要求步骤编号自动生成手写编号很麻烦尤其删除一个步骤后还要重排。EDD 里可以用自动编号规则解决。Element (Container: Step General rule: Step : TEXT Text format rules Basic format rules Autonumber: n1n0 Step ) )这里的关键是Autonumber规则n1表示当前编号器从 1 开始n0表示每遇到一个Step元素计数器加 1。FrameMaker 会自动维护编号删除或移动步骤后编号自动更新。用 EDD 定制的另一个好处是你可以在元素里加入通用属性比如Audience、Version然后在生成输出时按属性过滤内容。这种能力在传统 Word 式写作里很难实现但在结构化文档里是日常操作。5. 常见问题与排查技巧5.1 中文乱码大多数初学者的第一个坑我在用 MIF 生成中文文档时第一次遇到的坑就是乱码。FrameMaker 打开 .mif 文件后中文全变成了“”或者方框。排查下来主要有三种原因文件保存编码不对MIF 文件推荐保存为 UTF-8 with BOM。各种编辑器对 BOM 的处理不一样用 Windows 自带记事本另存为 UTF-8 时是带 BOM 的但用一些开发工具默认是无 BOM 的 UTF-8FrameMaker 识别上会有偏差。字体问题MIF 里如果没有指定中文字体FrameMaker 会用一个默认西文字体渲染中文结果就是乱码。建议在文件头部像前面示例那样用DefaultFont指定“宋体”或“思源黑体”这类中文字体。脚本写入时的编码转换用 Python 或 JavaScript 写 .mif 文件时要确保字符串以正确编码写入文件不能直接用默认 ASCII 编码。排查方法很简单新建一个只包含一段中文的 .mif用不同编码保存测试直到打开正常就把这个编码方案固化到你自己的模板里。5.2 版本差异老项目和新脚本怎么共存FrameMaker 的版本差异对自动化影响很大。2019 版引入了 ExtendScript但很多老项目还在用 FrameMaker 2017 甚至更早的版本这些老版本只有 FDK 和 MIF 两条路可走。如果团队内部版本不统一你写的 ExtendScript 在别人机器上可能直接运行不了。我的经验是做 MIF 相关的工具尽量用相对基础的标签元素避免深度依赖某个版本才有的语法做 ExtendScript 之前先确认所有使用者都升级到支持 ExtendScript 的版本。如果确实需要兼容老版本那就老老实实退回 MIF 加一些命令行批处理的方式别硬上脚本。另外FrameMaker 打开 MIF 文件的兼容性也需要注意。旧版的 FrameMaker 打开新版 MIF 可能会丢失某些属性而新版打开旧 MIF 一般问题不大。所以你自己产出的 MIF 文件最好用团队里最低版本的软件验证一遍。5.3 调试心得先备份、少批量、看日志最后分享几个我踩过多次坑之后总结的习惯第一不管写 MIF 还是 ExtendScript操作前一定要备份原文档。自动化脚本虽然方便但一旦逻辑有误很可能把整个文档的格式搅乱而且 FrameMaker 的 Undo 不一定能完全恢复。第二批量处理的时候先设置一个小范围跑一次。比如先只处理前 3 个表格或前 5 个段落确认结果符合预期再把范围扩展到全文档。别一上来就整篇跑万一出问题排查起来非常痛苦。第三多利用 FrameMaker 的日志和对象浏览器。ExtendScript 编辑器里通常有对象浏览器你可以查看当前文档对象的层级结构和所有属性。遇到 API 名称不确定的时候直接看对象浏览器比翻文档快得多。MIF 文件打开报错时FrameMaker 会给出大致错误位置虽然有时候不太准确但至少能定位到文件区域缩小排查范围。我自己的体会是FrameMaker 的自动化并不神秘套路就那么几种。初期把 MIF 和 ExtendScript 各跑通一个小例子后面再遇到批量改文档、生成表格、统一编号这类需求思路基本都是现成的。真要说有什么难的地方反倒是“先想清楚自己到底要改什么”这一步。文档结构越乱自动化脚本越难写所以动手之前花点时间理清文档里的段落标签、表格层级和编号规则比闷头写代码重要得多。本文还有配套的精品资源点击获取