简介：frameMaker是一个基于模板输出文本的通用工具，采用纯Java编写，模板引擎的核心思想是根据数据模型与模板文件自动生成所需文本内容。这份实例代码适合Java初学者、模板引擎爱好者以及需要快速生成文本/HTML的开发者，可帮助理解模板引擎的实际应用方式。压缩包共24个文件，体积仅13KB，包含Java源码、FTL模板、HTML页面、XML配置、class文件及项目元数据等，已有553人学习。其中两个FTL模板分别对应SimpleFTL与FTL1Servlet两个示例：前者执行main方法即可在控制台看到渲染结果，后者通过浏览器访问Servlet地址即可在网页中查看输出，非常便于对照学习。资源还保留了Eclipse/IDEA项目配置、Maven构建文件及Web工程相关设置，读者可以直接导入开发环境运行，快速掌握模板引擎的调用流程、模板语法以及Servlet集成方式。 做技术文档这些年，我几乎天天跟 Adobe FrameMaker 打交道。很多人对 FrameMaker 的印象停留在“一个排版软件”，但真正让它在技术文档领域站住脚的东西，其实是那套藏在菜单后面的自动化能力——FrameMaker 实例代码。不管是批量把 20 篇章节文件导出成 PDF，还是统一给每章加页脚、改字号、重排目录，只要把流程写成脚本，原本要干一下午的重复操作，往往几分钟就能跑完。
这篇博文会从实战角度讲清楚 FrameMaker 脚本的几条实现路线，再用一套可以直接抄走的实例代码把细节拆开。内容适合维护手册、说明书和大型技术文档的文档工程师，也适合刚接触 FrameMaker 但不知道从哪开始写自动化脚本的读者。基础概念我会先补充，不会一上来就甩一堆看不懂的代码。
1. FrameMaker 自动化脚本：四条路线怎么选
1.1 先分清你要解决什么问题
先泼一盆冷水：不要为了自动化而自动化。一次性的文档修修补补，直接在界面上动手更快。我自己见过不少同事，为了“看起来专业”，把一个只需要改两段文字的小任务硬写成脚本，结果调试脚本的时间比手工做还长。真正值得写脚本的任务，通常有三个特征：重复度高、改动范围大、需要跨多文档统一操作。
举个例子，一套产品手册按章节拆成 20 个 .fm 文件，这周要统一定稿，每章结尾都要加同样的版权落款，还要重新导出 PDF。这种任务如果靠手，至少一个半小时，人还容易漏。但同样的流程写成脚本，一次跑完 20 个文件，误差为零，以后每次升级版本都能复用。所以接到任务先别急着打开 FrameMaker，耐心想五分钟：这个动作后面还会不会再做？如果答案是“会”，那脚本就是值得投入的。
1.2 FrameScript、ExtendScript、MIF、EDD/DTD 各自定位
FrameMaker 的自动化路线比很多人想的多，我先用一张表把主流方式捋清楚：
| 路线 | 本质 | 适合谁 | 典型场景 |
|---|---|---|---|
| FrameScript | 类英语的脚本语言 | 懂一点宏的文档人员 | 批量改格式、替换文本、控制打印输出 |
| ExtendScript | Adobe 统一的 JavaScript 引擎 | 会 JavaScript 的开发者 | 复杂业务逻辑、跨文档处理、界面交互 |
| MIF | 文档交换文本格式 | 需要程序生成文档的后台开发 | 自动生成文档骨架、内容迁移与转换 |
| EDD/DTD | 结构化文档定义 | 长期维护结构化手册的团队 | 定义元素规则、约束文档结构 |
先说 FrameScript。它是最贴近“界面操作”的脚本语言，语法读起来像英语句子，上手门槛低。缺点是它的生态相对封闭，一旦逻辑变复杂——比如要遍历文件夹、做字符串拼接——写起来会有点别扭。
ExtendScript 则是 Adobe 为了统一旗下软件脚本体验推出的 JavaScript 引擎，可以从较新版本的 FrameMaker 里直接调用。它的好处是只要你会 JavaScript，就能很快上手复杂逻辑，而且跟 InDesign、Illustrator 等其他 Adobe 工具连动很方便。我自己的偏好是：简单的替换和格式修改用 FrameScript，凡是带循环、条件、跨文件处理的活，一律用 ExtendScript。
MIF 的定位不太一样，它不依赖 FrameMaker 界面，是一种纯文本的中间格式。你可以用 Python、Java 或者任何文本工具生成 MIF 文件，再用 FrameMaker 打开后转成正式文档。这个方案特别适合从数据库批量生成文档初稿。EDD/DTD 则属于结构化文档范畴，它本身不是“实例代码”，但如果你想把内容和排版彻底分离，EDD 定义了哪些元素能用、怎么嵌套、属性怎么约束，代码生成的内容才够干净。
2. 核心细节解析：FrameScript 代码的骨架与常用套路
2.1 FrameScript 的“英语化语法”最小示例
FrameScript 最吸引人的地方就是它读起来像句子。比如你想打开一个文档、全选、替换文字、保存关闭，写出来大致是这样：
OpenDoc("C:/Docs/Chapter1.fm") SelectAll() FindText("\"TODO\"") ReplaceText("已确认") SaveDoc() CloseDoc(0)这段代码的可读性非常高，你对照着界面里的操作一解释，非技术背景的编辑也能看懂个大概。执行方式是：File > Scripts 里选择运行脚本，或者把语句直接敲进脚本编辑器逐行测试。需要注意，上面是常见示意写法，不同 FrameMaker 版本的函数名和参数会有细微差别，动手前最好翻一下当前版本的脚本指南。
我用的比较高频的 FrameScript 动作大概这么几类：
- OpenDoc / NewDoc / CloseDoc：打开、新建、关闭文档
- SaveDoc / SaveAsDoc：保存文档，或另存
- SelectAll / FindText / ReplaceText：选择、查找、替换
- SetDocProp / SetParaProp：设置文档属性和段落属性
- SetTextFormat：给选中文本直接套用格式
这些动作几乎就是把手工操作“原样翻译”成脚本。最初不熟的时候，我会打开 FrameMaker 的记录功能，自己在界面里操作一遍，然后看脚本自动记录，慢慢就能总结出常用的语句模板。
2.2 ExtendScript 的实战姿势
如果你已经会 JavaScript，那 ExtendScript 上手会顺畅得多。FrameMaker 开放接口之后，最标准的打开文档并导出 PDF 的脚本是这种感觉：
var doc = app.Open("C:/Docs/Chapter1.fm"); var pdfPath = "C:/Docs/PdfOut/Chapter1.pdf"; app.Export(ExportFormat.PDF, pdfPath); doc.Save(); doc.Close();这段代码里有几个关键概念。app是全局对象，代表 FrameMaker 应用本身；Open方法打开一个文档，返回文档对象；Export负责输出。真正让新手迷惑的是“某类操作应该调用谁”——是文档对象的方法还是 app 全局的方法。我的判断依据很简单：这个操作跟“当前文档”的状态关系大不大？比如保存、关闭、获取文本范围，这些明显跟某个文档绑定，就去找 doc 的方法；比如设置首选项、遍历应用打开的文档、导出时选择输出格式，就优先找 app 全局方法。
运行 ExtendScript 的方式通常是 Tools > ExtendScript 或者 FrameMaker 自带的脚本编辑器，也可以把 .jsx 文件直接拖进 FrameMaker 执行。我习惯先开控制台逐行调试，确认每个步骤没有报错，再保存成完整脚本文件去批量跑。这里有一个很实用的习惯：第一次运行脚本时，文件名和路径里不要带空格和中文，很多诡异问题都是路径解析引起的。
2.3 MIF：把 .fm 文件当文本处理
MIF 是 FrameMaker 的中间交换格式，它把文档的段落、字符、表格、图形锚点全部用文本形式描述。可以把它理解成 FrameMaker 的“明文底稿”——只要拿到 MIF，你就能在程序侧直接生成一个 FrameMaker 能打开的文档。
一个很简化的 MIF 结构长这样：
<MIFFile 9.0> <Units Ucm> <Doc> <DefaultFont <Family `Times'> <Size 10> > <Para <PgfTag `Body'> <String `这是正文第一段'> > </Doc>这个文本存成 .mif 后，用 FrameMaker 打开就能看到一段带默认字体的正文。MIF 的语法很直白：标签加尖括号，文本用反引号包起来，缩进表示嵌套层级。可能刚接触的人会被一堆标签吓到，但常用到的其实就那么几个。
MIF 方案最大的价值是“不依赖 FrameMaker 就能拼出文档”。比如从数据库里抽出产品型号、参数、版本说明，用 Python 脚本按模板输出 MIF 文件，再批量打开转成正式 FM 文档。这套路在内容量很大的产品线里特别好用，我见过有团队每年靠这个流程自动生成上千页的规格书初稿，效率比手动建文档高出一个数量级。
3. 实操过程：做一个“批量给每章加统一落款图”的脚本
3.1 需求与设计思路
场景很具体：我维护的一套产品手册，按章节拆成 20 个 .fm 文件，这次发布新版本，要求每章最后都放一张统一的“公司落款 + 免责声明”图片，再导出新 PDF。手工做的流程是：打开文件、滚动到末尾、插入图片、调整尺寸、导出 PDF、关闭文件，重复 20 轮。
我的设计思路是先定流程，再想代码。整体分五步：
- 确定文件列表，放在同一个文件夹里。
- 用 ExtendScript 遍历所有 .fm 文件。
- 对每个文档，在正文末尾插入指定的落款图片。
- 保存文档，并导出同名 PDF 到输出目录。
- 批量操作前先把原文件全部备份一份，防止脚本逻辑有误无法回退。
这个场景选 ExtendScript 而不是 FrameScript，原因很直接：流程里有数组遍历、字符串拼接、文件名替换、条件判断这些逻辑，用 JavaScript 写维护起来更顺手。FrameScript 做简单替换确实快，但遇到这种需要“遍历全部文件、动态生成输出名”的活，JS 的代码可读性和容错性都更好。
3.2 实例代码：批量处理章节文件
下面是一段可在 FrameMaker 的 ExtendScript 环境里运行的示意代码，API 名称我按常见写法给出，具体使用前建议对照你自己版本的脚本指南调整：
// 批量处理章节文件：插入落款图片并导出 PDF var fileList = [ "C:/Docs/Chapters/Chapter1.fm", "C:/Docs/Chapters/Chapter2.fm", "C:/Docs/Chapters/Chapter3.fm" ]; var imgPath = "C:/Assets/Footer.png"; var outFolder = "C:/Docs/PdfOut"; for (var i = 0; i < fileList.length; i++) { var doc = app.Open(fileList[i]); // 获取文档的主故事，跳到文末 var story = doc.MainStory; var endLoc = story.TextEnd; // 在文末插入图片（示意方法，不同版本 API 略有差异） story.InsertImage(endLoc, imgPath); // 保存文档 doc.Save(); // 导出 PDF，文件名保持与源文件一致 var pdfName = fileList[i].split("/").pop().replace(".fm", ".pdf"); app.Export(ExportFormat.PDF, outFolder + "/" + pdfName); doc.Close(); }读代码的时候，有三个容易踩坑的位置值得反复看。第一，doc.MainStory是获取文档主故事的方式，但有些文档拆成了多个故事，需要先确认主故事确实覆盖了正文内容，否则图片会插到没人注意的角落里。第二，插入图片的路径必须是绝对路径，斜杠方向建议统一用正斜杠，Windows 下如果用了反斜杠，很多字符串拼接场景会出转义问题。第三，导出 PDF 时 FrameMaker 默认可能弹出各种对话框，我一般提前在首选项里把“导出时显示交互对话框”关掉，否则脚本跑到一半会卡住等人点按钮。
文件列表我也建议从实际项目里抽出来而不是硬编码。你可以用脚本工具直接扫描文件夹里的 .fm 文件，也可以像我这样先手动维护一个数组。硬编码最大的好处是每次处理顺序可控，不会因为文件夹里混入其他文件而出错。
3.3 运行步骤与参数调整
实际执行的时候，我一般分三步走。第一步，复制一份完整文档目录出来，在副本上先跑 3 个文件，确认生成的 PDF 里图片位置正确、格式没有乱，再跑全量。第二步，全量跑之前，把 FrameMaker 的“保存文档时自动备份”选项打开，即使脚本逻辑有问题也有兜底文件。第三步，跑完后随机抽查几个输出 PDF，重点看每章最后一页是否有落款图、图片有没有被正文文字覆盖。
我这次实际遇到的调整问题是：落款图在部分章节里被挤到了新一页。原因很好理解——有些章节的最后一页本来就接近满版，图插入正文末尾后自然被推到下一页。解决办法是把图片宽度从最初的 12cm 缩到 10cm，并把图片锚点从“跟随文字流”改成“固定于页面角落”。这个调整只需要改脚本里的两个参数再重新跑一遍，比手工改 20 个文件舒服太多了。这也是脚本集中管理的价值：格式规则一改，全量文档立即生效。
4. 常见问题与排查技巧实录
4.1 “方法找不到”类的报错
FrameMaker 脚本经验不深的人，最容易遇到类似“cannot find method”的报错。说实话，这种报错大多数不是你的逻辑问题，而是 API 版本差异。FrameMaker 脚本 API 在大版本之间也可能变化，网上抄来的代码很难保证跟你本机一致。遇到这种报错，我通常会按顺序做三件事：查当前版本带的 SDK 文档，看 API 有没有改名；确认函数挂在哪个对象下面——文档对象、故事对象还是全局 app 对象；再检查参数个数和类型。比如导出 PDF 这个操作，有的版本挂在 app 下，有的版本入口在 doc 下，凭记忆硬套最容易翻车。
4.2 图片导入后位置跑偏
图片位置跑偏基本是两类原因：单位和锚点。FrameMaker 内部默认使用 point 作为单位，如果你在脚本里直接写 10cm，必须先转成 point 再赋值，否则图片会小得离谱。锚点问题也很典型：要明确插入的是“跟随文字流”的行内图，还是“固定于页面位置”的浮动图。固定图需要指定页面编号和坐标，坐标原点默认在页面左上角，单位同样是 point。我建议在脚本开头统一写一个单位转换函数，这样后面所有涉及尺寸的代码都不容易出错。
4.3 中文字体不显示或变成方框
中文字体在 FrameMaker 里是长期老大难，脚本设置字体时尤其明显。最常见的现象是：英文显示正常，中文全变成方框。原因通常是文档默认字体是西文字体，脚本又把格式强制改成某个西文字体族，导致中文字符没有可用字形。解决方法是：在脚本里把字体族设置为“思源黑体”“微软雅黑”这类带 CJK 字形的字体，同时设置字符属性的中日韩文字设置，让中文走正确字体。我自己早期吃过这个亏，后来习惯在脚本里同时设置三种字体属性——西文、中文和标点——才算彻底解决乱码。
4.4 大批量运行的性能问题
文件一多，脚本慢是小事，频繁报错才是大事。我的原则是：批量任务按 20-50 个文件为一批，每批跑完写一条日志，再继续下一批。同时在循环体里每处理完一个文件就马上doc.Close()，把内存释放掉，不然 FrameMaker 打开的文件越来越多，脚本会越跑越慢，甚至直接无响应。另外，如果某个文件有问题导致脚本中断，日志能帮你定位到具体是哪个文件、哪一步出的错，不用从头排查。
5. 最后分享一点我的小习惯
写 FrameMaker 脚本，我最大的体会是：真正值钱的不是某一段代码，而是你们团队沉淀下来的脚本套路。比如统一的目录命名、图片参数、PDF 输出规则，这些写进脚本模板之后，新入职的同事也能用同一个脚本跑出发行版文件，不依赖谁记得住手工流程。
另外，千万别把脚本当成一次性工具。这次批量加落款图的脚本，我后来在原基础上加了一个读取配置文件的步骤，把落款图片路径、输出目录、图片尺寸都放到 config.txt 里。下次换项目，只要改配置文件就能复用，代码一行都不用动。这是我觉得 FrameMaker 自动化最有价值的地方——它能持续省力，而不是只临时顶一次班。
本文还有配套的精品资源，点击获取
