最近的一些工作都是在搞pdf文件的处理，整合了各种各样的包（pdf.js,?pdf-lib, downlaod.js...）,以及自己写and抄了各种各样的工具函数（arrayBufferToFile, checkFileType, ArrayBufferToBase64...），熟悉了各种平常用不到接口（canvas, blob...）
?
毕设只是对pdf上绘制canvas层做了一些研究，工作之后开始真正处理pdf了。不如做一些有意义的事情吧。
"技术是开源的，业务是私有的"
基于已有的业务对代码进行抽象，封装成一个工具类，再整合一些通用的pdf文件处理函数，主要是为pdf添加数字签名这一功能服务。最后打包到npm，开源到github。
这么做的目的如下：
1.锻炼自己对代码的抽象能力，强迫自己把业务代码和工具代码分离
2.发布之后有动力不断维护和迭代，这是我的起点，第一个开源包不会是我的终点
3.帮助之后的同事不再苦恼于将业务抽象为代码，变成 业务驱动代码
4.开源超酷的 👴
务实一点，第一轮的迭代要做的事情：
1. 抽离各种常量到ts文件，例如image宽高，pdf元数据的配置
2. 封装canvas绘制函数，基于pdf-lib 和 pdfjs，优先基于业务，也就是添加电子签名。考虑多种pdf情况，暂时遇到的为 签名透明度 和 pdf旋转的问题。
3. 封装主要的且通用的文件处理函数（这一步事情比较多，优先服务于电子签名业务）
4.改进pdf-lib的缺点：不支持传入blob或者file，不支持通用的图片类型判断
另外的一些想法：
可能在做的过程中出现很多奇妙的点子，如果有就先记录在这篇blog里吧。另外得考虑第一轮迭代的开发周期，点子太多反而会没法完美的去实现，暂时先保证电子签名这一个业务的完整性。
真实场景远比自己想的要复杂，可能三个周期也的迭代之后，这个库还是会很烂，不过问题不大，充满激情，持续维护。
I name this library “UIHpdfProcesser” : )
2022/6/24?
今天先把rep建好了，在公司建立的仓库连到了公司的镜像仓库了，无语，还是自己电脑上搞吧。
2022/6/25
今天顺利从github把包发到npm了，接下来就是考虑进一步封装代码。
常量一定的抽离成一个文件的，当作参数传入进去的。这边还需要考虑要不使用OO编程？
今天再研究一下好了。
?