Calcitem

考虑把GBK和BIG5的字符抽离到单独文件中来定义？

如果PDF查看器的功能 PDFPatcher 都要实现一遍的话，估计名称不能叫 Patcher 了，得改叫 YAA (Yet Another Acrobat) 。😂

如能最终有一个开源 Acrobat 当然是非常乐见的，不过，想探讨的是，PDFPatcher 存在的高价值在于弥补PDF工具的不足，抓住了痛点。既然随便一个PDF查看器都拥有的基本功能，定位于功能拓展的PDFPatcher 有什么理由要实现呢？我是感觉投入产出不成正比。

建议打包为zip，7z很多人可能不会装。 .gitattributes 文件需同步更新。

LGTM

忽视了一个事情，其实原本的打包方式就是7z，既然没有用户反馈，估计普及率已经很高。可能是不需要换zip的。项目lead来决定吧。

如果是测试版的话可以勾选 Pre-Release 复选框。

AGPLv3 要求与之组合的组件必须是 AGPLv3 或者 GPLv3 [兼容](https://www.gnu.org/licenses/license-compatibility.zh-cn.html)的许可证，不过目前有2个第三方组件 [tabcontrol-extra](https://github.com/tradewright/tabcontrol-extra/blob/master/License.md) 和 PowerJSON 使用的 [CPOL](https://blog.csdn.net/testcs_dn/article/details/53147140) 许可证和 GPLv3 不兼容。之所以不兼容是因为 CPOL 中有关 "您不得在本作品上提供或强加任何条款来更改或限制本许可证的条款或收受者行使本协议授予的权利。" 的条款和 GPL 有关 "传播则必须开源" 的条款抵触 。 因此我现在正在研究如何处理不[兼容](https://www.gnu.org/licenses/gpl-faq.zh-cn.html#WhatDoesCompatMean)的组件，将其原来为链接的方式改为[剥离为独立进程](https://www.gnu.org/licenses/gpl-faq.zh-cn.html#ManyDifferentLicenses)或者换用许可证兼容的组件。当然分离为独立进程不能说就没有风险，这只能由律师来解释，不过[业界规避 GPL 通常都是用分离进程这种方式来做的](https://www.v2ex.com/t/825728)。 我更倾向于处理 AGPLv3 的部分，共涉及 [iTextSharp](https://github.com/itext/itextsharp/blob/develop/LICENSE.md)...

> 考虑更换AGPL依赖项？ 那就比分离进程复杂多了，需要找替代品。如果你那边找到了可以贴一个评估看看。 一般C/C++编写的此类可移植性高的通用组件是业界最佳实践和最优解法的集合，不太容易换掉的。如果是其他语言则往往每个语言自己重复实现一套的情况还比较多。

> 但是MuPDF影响面比较大，建议新开一个branch逐步替代掉，引入松授权的库；如上面的PDFium。 支持新开 branch，以免影响主干的演进。 发现 [Patagames](https://github.com/Patagames) 制作了一个 Pdfium 的 C#版本：https://github.com/Patagames/Pdf.WinForms