ToolBox
家里有孩子的都知道，几乎每天都要打印作业。很多时候，老师发来的是"A3 试卷"或者材料，大多是 PDF 的，而且是横版的。但是，家里一般都是 A4 的打印机，怎么打？直接打印到 A4，那太小了，孩子写着费眼睛，老师改着也麻烦。
以前我基本都是自己手动切图，然后复制回 Word，再调整大小尺寸，最后打印。这个过程少说也得 10 分钟，虽然时间不长，但是过程重复，每次都要做同样的事情。这类事情最容易程序化，所以干脆把它做成小程序工具，下次直接用就可以了。
那怎么开始开发呢？肯定要先梳理需求点。根据自己使用的过程，我梳理了几个需求点："识别方向"、"切分图片"、"粘贴回 Word"、"排版"。
架构应该怎么定
我一开始想把核心处理全塞进"微信云函数"，跟工具箱里别的功能一样省事。试了才发现走不通。"PDF 渲染"、"图像处理"、"Word 生成"这三块分别依赖 pdfjs-dist、sharp、docx，在云函数环境里要么原生绑定缺失直接报错，要么内存和体积超限跑不起来。最后只能换了思路，用"三层混合架构"。小程序端负责选图和展示，"独立 Node 服务器"跑核心处理，云函数只做文件存储和转发，把文件从云存储转发到服务器、再把结果传回来。云函数不再处理文件，把处理工作交给能灵活调参、用 Docker 隔离的独立服务器，这样云函数就不再报错了。
如何确定旋转方向
整件事里最难的是判断试卷方向。"A3 对折"拍成照片，可能是横的也可能是竖的，左右两半谁在上谁在下也不一定，方向不对切出来就是乱的。我前后换了四版方案。第一版用"像素投影法"统计文字行数，但很快发现它分不清顺时针 90 度还是 270 度。第二版改成"上下密度分析"，借英文里 g、p、y 这种下伸字母判断，可中文试卷根本没有这种稳定信号。第三版比左半页上下区域的密度，多页独立检测又出现"同一份卷子前后页方向不一致"的怪事。最后是用"腾讯云 OCR"识别出文字块，再对整份卷子做"全局投票"决定方向，准确率最高，多页也能保持一致。如果出来的结果错误，用户还可以自己选择"不旋转"、"左旋"、"右旋"三种模式，避免识别不对的情况。
性能也是个问题
六页卷子处理要将近 79 秒，而云函数最长也只能处理 60 秒就会强制断连。还有内存问题，我独立服务器的峰值内存冲到 256MB 触发 OOM，我们被迫临时把容器内存顶到 768MB 才能用，但是我服务器内存紧张，要长期运行，必须控制在 256MB 以下。300DPI 渲染每页 canvas 就有 35MB，六页就是 200MB 往上；每页还要调两次 OCR，六页十二次串行等待；sharp 还反复解析 PNG 中间产物。那只能在处理的时候牺牲质量了。把渲染分辨率从 300DPI 降到 144DPI，每页 canvas 从 35MB 掉到 9MB，峰值内存降了七成；OCR 图片从 800 像素压到 600、质量从 70 降到 60，base64 体积少了四成。容器内存降回 256M 以内。处理时长也缩短不少。最后实测，4 页 A3 的卷子，最终 40 秒左右返回。基本满足日常需求，再多的话最好分开处理吧，我的服务器资源有限只能做到这些了。
网站版也能用
如果有大批量的处理，也可以使用我的网站的转换工具，这个纯浏览器处理，能批量处理、手动旋转、导出操作，适合大量文件处理。
地址：试卷资料转换
最后总结
从"手动切图旋正粘 Word"到"一步出文档"，中间是架构选型、方向检测四轮迭代、性能降档一连串的取舍。现在家长群里再有人问"A3 卷子怎么打"，把智图宝小程序甩过去就行。
—— 首发于公众号「键盘漫笔」