我可以不思进取，用一个过时的组件，应付当下的需求；我也可以勤奋好学，再找一个免费组件学习理解重新接入；也或者我可以花点钱买个版本结束这个问题，毕竟，能用钱解决的问题都不是大问题；实在不行，我们自己研发，彻底解决这个问题。这个过程很纠结，四个思路我都考虑过。
继续在新项目中使用已弃用的 iTextSharp (https://github.com/itext/itextsharp) ，从 .NET Framework 4.8 迁移到 .NET 8？或者使用最近火起来的 QuestPDF (https://github.com/QuestPDF/QuestPDF)？我参与了这个项目的中文文件大小临时处理方案，一年过去了死活不能彻底解决中文PDF文件过大的问题，或许永远无法解决？而且突然更改了授权，营收超过一百万需要支付授权费。付费的方案，看了看 ABCpdf (https://www.websupergoo.com/abcpdf-1.aspx)，我自己一个人用479美刀，如果我用在我们公司的SaaS服务中，需要支付4790美刀，你以为狠狠心花钱就可以解决所有问题？绝对不可能，还得学习它，研究它，把它用起来，或者用到一半，有问题怎么办？这就是软件！
在2022年的时候就考虑过重复造轮子，那时候认真读了三分之一的手册，纯英文，网上也没有多少案例，以为借助 ChatGPT 和 Copilot 可以辅助学习，发现人工智能不懂装懂的本事一点不比我差，很难啃，很痛苦，当时放弃了，但回过头来考虑别的方案，同样头疼不已。绕不过去的路，绕来绕去还得重新来走。这样的一个小需求所走过的路，就是实实在在的证明：自主研发，没有捷径可走。
于是乎，一个多月，继续啃完三分之一的手册，边学习边动手，一点一点的往前走，重新走，总算是走出了一条路。哪怕还有很多的问题需要解决，哪怕时间资源的投入如果换算成金钱，会让人觉得是否有必要，但这是自己的地盘了，我的地盘我做主！
一张图演示一下成果，可以从代码或者解析HTML代码获得，细节请访问：https://github.com/ETSOO/com.etsoo.EasyPdf
PDF文件：
