2022/6/23 近期的一些计划，关于发布开源包到npm

最近的一些工作都是在搞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编程？

今天再研究一下好了。

2022/6/27

今天的一些思考🤔

1.0.1版本的缺点，常量没有分离。关于定制化签名函数中，没有把电子签名stringArray写成可任意长度的，关于这个问题比较难解决，签名个数是钉死的，位置也是定死的，这个没办法写成一个通用的工具函数。

或者可以对单个签名的添加写成工具函数？多次调用？

暂时写了一版本，针对添加单个电子签名的function

 

2022/6/28 

今天修bug发现的问题，添加签名函数返回的是一个promise<ArrayBufferLike>，这个需要在readme中说明一下。