先说一个我最近遇到的场景。同事给我丢来一张客户发来的设计稿截图里面有一句参考文案让我帮忙“把字弄出来”。我打开截图放大、眯着眼睛敲字的功夫一分钟就没了。后来我仔细想了想Photoshop作为设计师的日常主战场居然没有一个顺手的“图片文字提取”入口。外部OCR工具确实好用但每用一次就要切窗口、粘贴图片、复制结果来回折腾半天。于是我就动手做了个小东西一个跑在Photoshop面板里的CEP插件内置OCR文字识别能力。打开面板点一下按钮当前文档里的文字就被识别出来还能按位置回填成可编辑的文字图层。前前后后折腾了几个周末踩了不少坑也沉淀出一套完整可复制的实现方案。这篇文章就把整个开发过程拆开讲透包括CEP插件架构、OCR引擎选型、UI和ExtendScript桥接、图片数据流转、结果回填坐标处理以及那些文档里根本不会写的问题。1. 为什么要在Photoshop里做OCR文字识别插件1.1 设计师的“抠字”需求比想象中频繁很多人以为OCR是文档办公场景的需求但我在实际接触中感受最深的反而是设计场景。数一数平时会遇到的情况从网上找的素材图标、海报截图里有一段文字想改成自己的话但原图是栅格化的没法直接编辑。客户发来的JPG版参考稿里面写了几个关键说明想快速转成文档再整理。从纸质扫描件、书籍翻拍照片里摘录段落文字手动敲又累又容易错。需要把图片里某段文字复制到另一个设计文件但不想经过外部软件中转。这些场景共同的特征是文字已经“栅格化”了PS本身没有自带“从图片中识别文字”的稳定功能。虽然偶尔有云服务支持但普通用户依赖的还是本地环境。1.2 为什么不用现成的外部OCR工具市面上截图OCR工具确实不少手机上也有一堆“图片转文字”App。但它们和Photoshop配合使用时问题很明显。操作链路太长。需要先截取PS画布区域切到OCR工具粘贴或导入图片识别完成后再复制结果最后回到PS粘贴。整个过程在多个窗口之间来回切换识别稍微出点错还得重复一遍。画面范围误差。PS画布上经常有参考线、选区、辅助图层截图工具没法精确理解“到底选哪一块区域识别”。而如果在PS里先做选区再截图又增加一步。隐私问题。很多在线OCR工具需要把图片传到第三方服务器客户给的源文件、未发布的设计稿都不太适合随便上传。把这些痛点摆在一起答案就清晰了OCR能力应该被做成一个内部原生工具塞进PS本身的工作流里。用户选中一个图层点一下按钮结果直接出现在旁边整个过程不出PS。这就是CEP插件能做的事情。1.3 这个插件最终做到了什么整个项目做完以后功能大概是这样的提供一个常驻在“扩展程序”菜单下的面板打开就是OCR操作区。点击“识别当前文档”自动导出一份PNG临时图调用OCR引擎识别。识别出的全文显示在面板文本区内方便复制。支持把识别结果按单词或按行回填到当前文档自动生成文字图层。保留OCR返回的坐标信息文字图层位置尽量贴近原文区域。中文、英文混合识别不需要外网所有计算都在本机完成。整个项目对Photoshop版本的要求不高只要是基于CEP架构的版本CS6之后的绝大多数版本都能适配我用的是2021测试开发思路完全通用。2. CEP架构与OCR引擎选型为什么是Tesseract.js2.1 CEP插件是什么能做什么不能做什么CEPCommon Extendable Platform是Adobe系列软件通用的扩展平台。简单理解它就是把一个内置的Chromium浏览器窗口嵌到PS界面里让我们用HTML、CSS、JavaScript画界面同时还能通过一套桥接机制调用Photoshop自身的脚本能力。CEP能干的事很多在面板中显示Web页面表单、按钮、图表都能做。通过ExtendScript也就是常说的JSX脚本控制PS文档、图层、选区、导出等操作。让面板JavaScript和JSX脚本互相传值完成“点击按钮 - 执行PS操作 - 返回结果”的闭环。面板还能开启Node.js支持直接读写本地文件系统。但CEP也有明显的边界它本质上是Web前端不适合做重计算绘制图像和像素级处理必须交给PS内部的脚本完成。这也决定了我们的整体架构UI用Web技术OCR识别放在JavaScript侧或Node侧像素相关操作走JSX。2.2 OCR引擎选型对比选OCR引擎是整个项目最关键的决策。当时我列了一个对比表。方案部署方式网络依赖中文识别成本典型场景Tesseract.js纯前端JS库可直接嵌入CEP首次可能需要下载语言包之后离线可用中等chi_sim语言包免费本地轻量识别、离线场景PaddleOCR需要运行Python服务依赖本地服务高免费高精度离线服务百度/腾讯/阿里云OCRHTTP API调用必须联网高按量计费高精度、可控成本Tesseract原生命令行或C库不需要中等免费服务端批处理我最终选了Tesseract.js理由很实际。首先它能在CEP的JavaScript环境里直接跑不需要额外部署Python或Node服务整个插件就是个纯文件夹拷贝到扩展目录就能用。其次识别过程完全在本地完成设计稿不会上传到任何地方对没有网络环境的内网用户也友好。再一个它免费不涉及账号、密钥、额度管理。它也有明显短板中文识别准确率不如商业云服务尤其对复杂背景、艺术字体、弯曲文字表现一般。但这个短板可以通过预处理和算法调优来缓解而且对“提取规范字体、印刷体文字”的场景已经够用。如果哪天需要更高准确率架构上也预留了切换云端API的接口。2.3 整体架构一句话总结插件采用了一个很典型的三层结构UI层client目录HTML CSS JavaScript负责显示面板、接收用户操作、展示识别结果。桥接层CSInterface调用evalScript在UI JavaScript和PS宿主JSX之间传递命令和数据。宿主层host目录ExtendScriptJSX直接操作Photoshop文档完成导出图片、创建文字图层等操作。OCR识别引擎作为独立的JavaScript库挂在UI层里跟宿主JSX之间不直接交互全部通过面板JavaScript中转。这样分层的好处是职责清晰哪块出问题能立刻定位。3. 工程骨架与调试环境快速把空面板跑起来3.1 环境准备开发CEP插件需要准备这么几样东西Photoshop本体建议2021以上版本底层CEP版本较高浏览器内核也较新。Node.js仅开发阶段用来做工具链辅助插件运行不依赖它Node被内嵌在CEP运行时里。Chrome或者基于Chromium的浏览器用来调试面板UI。一个文本编辑器VS Code就挺好。不需要安装额外的“CEP开发工具包”核心的几个库文件CSInterface.js网上有开源版本Adobe的CEP环境里也自带复制一份到项目里就行。3.2 目录结构设计一个标准的CEP插件项目目录长这样ps-ocr-panel/ ├── CSXS/ │ └── manifest.xml // 插件注册清单最关键的文件 ├── client/ │ ├── index.html // 面板界面 │ ├── css/ │ │ └── style.css │ ├── js/ │ │ ├── CSInterface.js // Adobe提供的桥接工具库 │ │ ├── libs/ │ │ │ └── tesseract.min.js // OCR引擎 │ │ └── main.js // 面板交互逻辑 └── host/ └── ocr.jsx // 宿主端ExtendScript脚本最关键的是CSXS目录下的manifest.xml它告诉Photoshop“这是一个扩展、扩展叫什么名、UI入口在哪里、宿主脚本在哪里、需要开启哪些能力”。我的manifest配置如下?xml version1.0 encodingUTF-8? ExtensionManifest ExtensionBundleIdcom.example.psocr ExtensionBundleNamePS OCR ExtensionBundleVersion1.0.0 Version2.0 ExtensionList Extension Idcom.example.psocr.panel Version1.0.0 / /ExtensionList ExecutionEnvironment HostList Host NamePHXS Version[16.0,99.0] / /HostList LocaleList Locale CodeAll / /LocaleList RequiredRuntimeList RequiredRuntime NameCSXS Version9.0 / /RequiredRuntimeList /ExecutionEnvironment DispatchInfoList Extension Idcom.example.psocr.panel DispatchInfo Resources MainPath./client/index.html/MainPath ScriptPath./host/ocr.jsx/ScriptPath CEFCommandLine Parameter--enable-nodejs/Parameter /CEFCommandLine /Resources Lifecycle AutoVisibletrue/AutoVisible /Lifecycle UI TypePanel/Type MenuOCR文字识别/Menu Geometry Size Height480/Height Width360/Width /Size /Geometry /UI /DispatchInfo /Extension /DispatchInfoList /ExtensionManifest几个容易踩坑的点说明一下。Host NamePHXS代表Photoshop如果插件要兼容InDesign等其他Adobe软件可以加多个Host。Version[16.0,99.0]表示支持的宿主版本范围16.0大概对应CC 201799.0相当于“不设上限”这样比较省心。CEFCommandLine里追加--enable-nodejs非常关键。没加这个参数面板JavaScript里只要出现require(fs)就会直接报错后面我们读写临时文件时完全依赖Node的能力。ScriptPath指向宿主JSX脚本路径。这里有个容易忽略的细节Photoshop在加载扩展时并不会自动执行这个JSX它只是注册了“这个扩展关联了一个脚本文件”我们需要在UI JavaScript里通过evalScript去调用其中定义的函数。3.3 安装与首次运行开发时不需要打包安装。直接把整个项目文件夹放到Adobe的CEP扩展目录下即可Windows:C:\Users\用户名\AppData\Roaming\Adobe\CEP\extensions\macOS:~/Library/Application Support/Adobe/CEP/extensions/放好后重启Photoshop进入“增效工具 - 扩展程序”菜单就能看到“OCR文字识别”面板了。但有一个开发调试的坑必须先解决Windows下CEP默认不允许未签名的扩展“随意加载”不然面板在菜单里根本不会出现。需要修改注册表开启调试模式[HKEY_CURRENT_USER\Software\Adobe\CSXS.9] PlayerDebugMode1注意CSXS.9对应CEP 9如果你的Photoshop是2022以上版本可能是CSXS.10、CSXS.11改成对应数字即可。这一步不搞定后面全是白忙。4. 面板UI到JSX宿主桥接PS里跑通第一条命令4.1 桥接机制的基本原理CEP插件的面板页面跑在Chromium里JSX脚本跑在Photoshop进程里两边不直接通信所有调用都通过CSInterface的evalScript走一遍桥。简单理解evalScript就是把一行字符串交给Photoshop去执行。比如在面板JavaScript里写const cs new CSInterface(); cs.evalScript(alert(hello from PS));Photoshop会弹出一个脚本窗口。但实际开发中不能这么裸写因为要传递参数和接收返回值而JSX没有GSON那种自动序列化机制。我的习惯是把JSX里的函数封装好参数统一用JSON字符串传入函数内部解析返回值也统一包裹成JSON字符串传出。4.2 面板UI设计面板界面我做得比较克制一个按钮、一个文本域、几个可选参数就够了。HTML骨架如下!DOCTYPE html html head meta charsetutf-8 link relstylesheet hrefcss/style.css /head body div classapp h3OCR 文字识别/h3 div classrow button idbtnRecognize识别当前文档/button button idbtnExportText回填为文字图层/button /div labelinput typecheckbox idckbRenderBoxes checked 按识别区域回填/label textarea idresultText rows12 placeholder识别结果会显示在这里/textarea div idstatus/div /div script srcjs/CSInterface.js/script script srcjs/libs/tesseract.min.js/script script srcjs/main.js/script /body /htmlUI层不需要花里胡哨重点是逻辑闭环。4.3 第一条JSX命令的完整流程先测试一下桥是否通畅我在host/ocr.jsx里写一个最简单的函数#target photoshop function psOcrTest(params) { try { var arg JSON.parse(params || {}); return JSON.stringify({ ok: true, echo: arg.message || empty }); } catch (e) { return JSON.stringify({ ok: false, error: e.toString() }); } } // 必须告诉Photoshop哪些函数可以跨桥访问。 // 传统写法是用函数名反射调用做法是给所有入口函数挂在全局对象上。 $.global.psOcrTest psOcrTest;这里我用了$.global把函数挂到全局这样面板那边才能通过evalScript(psOcrTest(...))调用到。面板那边我在main.js里封装一个通用的调用方法const cs new CSInterface(); function callPsx(functionName, params) { return new Promise((resolve, reject) { const script functionName ( JSON.stringify(params) ); cs.evalScript(script, (result) { try { const obj JSON.parse(result); if (obj.ok) { resolve(obj); } else { reject(new Error(obj.error || unknown error)); } } catch (e) { reject(new Error(JSX返回格式异常: result)); } }); }); } document.getElementById(btnTest).addEventListener(click, async () { const res await callPsx(psOcrTest, { message: hello }); document.getElementById(status).textContent res.echo; });这一步跑通之后后面所有PS操作都可以复用这套模板先在JSX定义函数再通过evalScript调用返回的JSON里带ok标志和业务数据。这个模式看似简单却是我整个插件稳定性的根基。早期我图省事直接用evalScript执行拼接字符串的JSX代码参数里只要包含单引号或特殊符号就炸后来全面改成JSON传参问题彻底消失。5. 图片数据流转与识别核心这块最折腾5.1 从PS导出当前画布为PNGOCR识别的第一步是把Photoshop当前文档的可见内容导出成一张图片。这一步看起来简单实际上有讲究。我最开始的方案是用exportDocument导出整个画布。但在大图场景下几千像素宽的图传到OCR引擎里识别速度和内存占用都很夸张。后来我优化成“优先识别选区没选区再识别整个画布”。用户如果有明确的识别目标先用选区框一下识别速度和准确率都会明显提升。JSX侧的核心代码#target photoshop function psOcrExportDocument(params) { try { var arg JSON.parse(params || {}); var doc app.activeDocument; if (!doc) return JSON.stringify({ ok: false, error: 没有打开的文档 }); var outputFolder Folder.temp; var outputPath outputFolder.fsName /ps_ocr_export_ Date.now() .png; var exportOpts new ExportOptionsSaveForWeb(); exportOpts.format SaveDocumentType.PNG; exportOpts.PNG8 false; exportOpts.transparency false; exportOpts.quality 100; var exportTarget doc; // 如果有选区只导出选区范围 if (doc.selection doc.selection.bounds) { var bounds doc.selection.bounds; var x bounds[0].value; var y bounds[1].value; var w bounds[2].value - x; var h bounds[3].value - y; var tempDoc doc.duplicate(_ocr_temp_, true); tempDoc.crop([[x, y], [x w, y], [x w, y h], [x, y h]], 0, 0, 0); exportTarget tempDoc; } exportTarget.exportDocument(new File(outputPath), ExportType.SAVEFORWEB, exportOpts); return JSON.stringify({ ok: true, filePath: outputPath, docId: doc.id }); } catch (e) { return JSON.stringify({ ok: false, error: e.toString() }); } }这里有个小细节值得提Folder.temp是系统的临时目录路径由PS自己管理比硬编码C:/Temp要靠谱得多各种权限问题直接绕开。导出临时副本后还要记得清理。我在完整版本里写了个psOcrCleanup函数专门负责删除临时文档和临时PNG文件避免反复识别把系统临时目录堆满。5.2 面板侧用Node读取图片并触发识别导出PNG只是一步“把PS画布变成文件”的事。接下来要把这个文件交给Tesseract.js识别。这一步需要Node的fs模块读文件。之前manifest里增加的--enable-nodejs参数就是为这里准备的。面板侧代码const fs require(fs); const path require(path); async function runOcr(filePath, lang chi_simeng) { const base64 fs.readFileSync(filePath).toString(base64); const dataUrl data:image/png;base64, base64; const worker await Tesseract.createWorker({ logger: m { /* 可以输出进度到控制台 */ } }); await worker.loadLanguage(lang); await worker.initialize(lang); const { data } await worker.recognize(dataUrl); await worker.terminate(); return data; }重点说说这里容易踩的坑。第一Tesseract.js版本兼容性。CEP面板的Chromium虽然没有系统Chrome那么新也不是越新越好。我这里用的Tesseract.js v4/v5版本都试过v5的API更现代但对CEP旧版环境可能不友好。如果你在开发时遇到Tesseract is not defined或者createWorker is not a function先检查tesseract.min.js是否成功加载然后用console.log(window.Tesseract)确认全局对象存在。第二语言包问题。chi_simeng是“简体中文英文”的混合识别语言。Tesseract.js首次使用这个语言组合时需要下载对应的语言训练数据。如果机器能访问CDN它会自动下载如果内网环境或者访问不畅识别会一直卡住或者报错。我的做法是把语言包下载好放到插件的client/tessdata/目录下通过langPath参数指定本地路径await worker.loadLanguage(chi_sim);同时设置langPath: ./tessdata。这样整个插件就彻底不需要外网了。第三图片大小的限制。我测试过2000像素宽的图片识别速度还能接受再大就会明显变慢。导出时我会判断原始图片尺寸超过4000像素宽度就按比例缩小到2000再识别准确率几乎不受影响速度却快了很多倍。这步可以在JSX导出时做也可以在面板JS里做。5.3 识别结果结构解析与展示Tesseract识别返回的数据结构里有text、blocks、paragraphs、lines、words等层级。text是纯文本字符串直接展示给用户看没问题但要做“回填文字图层”的功能光有文本不够还需要每个单词的坐标框bbox。返回数据示例{ text: Hello 世界, words: [ { text: Hello, bbox: { x0: 10, y0: 20, x1: 60, y1: 40 } }, { text: 世界, bbox: { x0: 70, y0: 20, x1: 110, y1: 40 } } ] }面板拿到识别结果后我会把它缓存到全局变量里一个用于文本展示一个用于稍后的回填。展示层我直接渲染到textarea同时把每个word独自存储成数组确保“识别”“回填”两步解耦。这样用户可以先看一眼识别效果再决定要不要回填。6. 识别结果回填画布坐标、文字图层与实际效果6.1 回填的核心在指定坐标创建文字图层很多OCR插件止步于“输出纯文本”但作为PS插件不能回填画布就少了灵魂。我的回填逻辑分成两块整段文字回填和逐区域回填。整段文字回填实现起来最简单在画布中心创建一个文本图层把识别出来的全文填进去。代码不复杂function psOcrAddTextLayer(params) { try { var arg JSON.parse(params || {}); var doc app.activeDocument; var layer doc.artLayers.add(); layer.kind LayerKind.TEXT; layer.name OCR_ Date.now(); var textItem layer.textItem; textItem.contents arg.text; textItem.position [arg.x || 0, arg.y || 0]; textItem.size arg.size || 24; return JSON.stringify({ ok: true, layerId: layer.id }); } catch (e) { return JSON.stringify({ ok: false, error: e.toString() }); } }这里有一个值得注意的细节Photoshop文本图层的position属性指向的是文本框的定位点不是文字内容左上角。直接按OCR返回的(x0, y0)设定位置会出现一小段偏移。我后来修正的方法是position取OCR的(x0, y0)但这个“y”按PS的文本习惯更接近文字基线的位置所以回填后可接受度还可以用户做个微调就行。6.2 按识别区域回填让文字回到原来的位置整段回填适合“我就想把文字取出来重新排版”的情况。但很多时候你会希望识别出来的文字能覆盖在原位置上看起来几乎和原图一样只是变成了可编辑的矢量文本。这种需求就要做“逐区域回填”。实现思路是从OCR结果中拿到每个word的bbox坐标。把所有word按行聚类同一行的word合并成一个文字图层。每个图层用所在行的平均(x, y)作为位置。字体大小可以根据bbox高度估算fontSize boxHeight * 0.8经验系数。这个功能看着不难真正跑起来以后有个问题花了我不少时间OCR返回的坐标是从导出的PNG图片左上角算起的而Photoshop文档的坐标原点默认是画布左上角。如果用户文档的画布和导出的PNG尺寸完全一致坐标可以直接用。但一旦用户缩放画布、修改了标尺原点或者导出的图片做过缩放坐标就会偏移。我的解法是导出PNG时记录下导出区域在文档中的实际坐标识别完成后把OCR返回的(x, y)加上文档偏移量。准确公式是docX ocrX exportRegionX; docY ocrY exportRegionY;如果识别的是整个画布exportRegionX和exportRegionY都是0直接相减即可。6.3 校准字体大小让回填更自然OCR返回的bbox是包含该单词的矩形框高度大致等于文字实际高度加一点上下留白。用它估算字体大小有参考价值但不能直接用否则字体显示会过大或过小。我从实践里得出的经验公式是const fontSize Math.round(bboxHeight * 0.72);这个系数在不同字体下略有差异但作为默认值已经能让回填效果有八成相似度。如果对位置精确度要求高可以在回填后根据文字图层的bounds属性做一次“轮廓收缩”校准但那就属于锦上添花了。6.4 回填后的图层管理回填生成的文字图层我建议统一加一个命名前缀和颜色标签方便用户识别。我在JSX里做了个psOcrBackfill函数接收一个包含多个word文本、坐标、字体大小的数组循环创建图层并按原顺序放在图层堆栈最上层。function psOcrBackfill(params) { try { var arg JSON.parse(params || {}); var doc app.activeDocument; var items arg.items || []; items.forEach(function(item) { var layer doc.artLayers.add(); layer.kind LayerKind.TEXT; layer.name OCR_ (item.text || ).slice(0, 10); layer.textItem.contents item.text; layer.textItem.position [item.x, item.y]; layer.textItem.size item.size; }); return JSON.stringify({ ok: true, count: items.length }); } catch (e) { return JSON.stringify({ ok: false, error: e.toString() }); } }有一点需要提醒如果一次识别出的word有几百个循环创建图层会导致PS变得很慢甚至卡顿。我后来加了个上限逻辑默认一次回填不超过80个文本块把一个段落合并成一个文本块而不是逐单词创建既保留了排版近似度又不会卡死。7. 踩坑清单和性能调优别人踩过的坑就是你的时间7.1 面板白屏或菜单里找不到扩展这是新手第一次开发CEP插件时最高频的问题基本跑不掉。白屏的可能原因manifest.xml路径配错了MainPath指向的HTML文件不存在HTML脚本里有JS语法错误但面板区域直接白屏没有提示。解决方法就是打开开发调试工具看看控制台报错。面板右键菜单里有一项“检查元素”或者“Show DevTools”点一下就能看到CEF的开发者工具。菜单里看不到扩展的原因大概率是还没改注册表开启调试模式。上面已经写过Windows下要设置PlayerDebugMode1。另外修改manifest后必须完全退出Photoshop再重启某些情况下还需要清缓存。7.2require is not definedNode模式没生效我在开发时遇到过好几次这个报错。症状是面板页面打开后立刻报错所有的fs读取都用不了。原因就是manifest的CEFCommandLine没有配置或者没重启PS。修改完manifest后注意确认你编辑的是正确文件的正确位置标签名是CEFCommandLine不是CEFCommand。还有一种情况是--enable-nodejs确实加了但CEP会忽略重复加载的Node参数。如果还是不行先打开开发者工具确认typeof require的值如果还是undefined就要检查CEP版本是否支持Node集成CEP 6以上才支持Photoshop CC 2015之后基本都满足。7.3 Tesseract.js语言包加载失败这个问题常见于离线环境。表现为点击识别按钮后长时间停留在“加载语言”阶段或者直接报Error opening data。解决方法有两种一是提前把语言包下载好放到client/tessdata目录下然后在创建worker时设置langPath。 二是用Tesseract.recognize的简单API时它默认会去官方CDN下载。如果网络能通就让工人自动下载如果网络不通必须本地化。我最终采用了本地化方案整个插件目录大约增加了20MB体积但换来了彻底的离线使用体验值了。7.4 大图识别慢降采样和区域识别OCR识别的耗时和图片面积基本成正比。遇到一张3000x2000的图全图识别可能要吸干CPU好几分钟用户体验很差。我针对这个问题的优化组合是导出图片时做尺寸限制最大边超过2400像素就按比例缩放。支持选区识别。用户框选目标区域插件只导出选区部分识别速度提升非常明显。语言组合越少越快chi_simeng比chi_sim慢如果确定图片里没有英文就只加载chi_sim。识别时用worker.recognize(image, {}, { text: true, blocks: true })只请求必要的输出。7.5 识别准确率不够预处理大于调参试过用Tesseract的人都知道它对清晰印刷体的识别率不错但遇到彩色背景、阴影、艺术字体准确率会断崖式下跌。我能分享的实际经验是预处理对Tesseract的影响远大于调整识别参数。导出PNG之后我会在面板JavaScript里用简短的Canvas处理流程做灰度化、对比度拉伸和轻度降噪用Canvas把图片绘制一遍加上filter: grayscale(1) contrast(1.3)再交给OCR引擎。这样一来复杂背景图片的识别准确率从经常识别乱码提升到基本可用。当然如果你迫切需要“海报级艺术字体”的高精度识别Tesseract.js确实不够建议把引擎换成云端OCR API做一个可选的“云端模式”配置。插件的整体架构设计时就预留了这块扩展位面板里加一个模式切换下拉框即可。7.6 批量识别从单张到批量单个文档识别跑通之后批量识别就顺理成章了。PS本身有批处理功能但那个是针对动作的不适合动态调用OCR。我的实现方式是在JSX侧遍历文件菜单中的多个文档对每个文档依次调用导出并返回结果面板侧每导出一张就识别一张把结果拼到一个文本区。这个功能实现比较简单主要注意两点一是每个文档导出前要先把文档激活为app.activeDocument二是大批量操作时临时文件清理要及时防止磁盘被撑爆。收尾说点真心话整套插件从零到能稳定用前后大概花了三个周末。最难的部分不是OCR引擎而是CEP这个壳它文档少、报错晦涩、网上案例又少很多东西只能一点点试错。但一旦把骨架搭起来后面的迭代就很顺手了。如果你准备动手做类似的东西我的建议是前期花半小时把调试环境彻底打通注册表、DevTools、manifest这会节省你后面80%的时间。另外整个项目里最难复用的“公共JSX函数库”值得单独保存以后做任何PS插件都能用。最后分享一个优化经验在开发阶段我用console.log跟踪面板侧流程用$.writeln把JSX侧的调试信息写入临时日志文件。等面板DevTools窗口崩掉看不到日志的时候这个文件就是你唯一的救命稻草。别问我是怎么知道的。
