加密的 PDF 可以在不生成解密副本的情况下签署：LoadOptions 在原位打开文件，SaveOptions 决定签署后的输出是保留原密码还是使用新密码。本文比较了四种密码路径，包括两种会失败的情况，并解释了为何失败会以 RuntimeError 抛出，而不是 API 所列的异常类型。
26.9 版引入跨平台的 Project 文件渲染、Word 页码、DPI 设置，并移除 libgdiplus 依赖。
版本 26.9 引入了 ConversionEvents、新的图表格式、CAD 选项以及关键错误修复。
GroupDocs.Viewer for Java 26.9 引入 OFD 支持、PDF 注释渲染、DPI 设置、页码以及归档改进。
GroupDocs.Viewer for Node.js 26.9 添加了 OFD 支持、PDF 注释渲染、DPI 控制、页码、归档功能增强以及多项错误修复。
GroupDocs.Signature for Node.js 在进程中运行 JVM，因此容器化它意味着在任何签名工作之前必须预先配置 JDK 和字体。本文比较了选择字体族的三种方式——硬编码、从文件名检测或探测库——并介绍了影响代码实现的绑定细节。
在笔记本电脑上运行的 Python 签署脚本在 slim 容器中会失败两次：一次是因为 .NET 绑定缺少 libssl 或 libicu，二次是因为镜像没有字体且 GroupDocs.Signature 不会替代缺失的字体族。本教程构建了这两层以及保持脚本可移植性的解决代码。
GroupDocs.Signature 不会替代缺失的字体：如果指定镜像中不存在的字体族，调用会抛出错误而不是回退。由于 .NET 运行时镜像不包含任何字体，文本签名会因此失败，除非添加字体层。本文比较了无字体镜像与已修复的镜像，并展示了如何在运行时解析字体族。
Java 容器镜像捆绑了用于 AWT 的 DejaVu 字体，这足以签署英文文本，却不足以处理其他语言。本文探讨了这种部分覆盖对文档工作流的成本、为何 GroupDocs.Signature 会失败而不是替代，以及字体层加上运行时族解析如何将一次事故转化为启动检查。
法律和运营团队仍然会从合同 PDF 中泄露作者和 XMP。本指南比较了 GroupDocs.Metadata for .NET 中完整的 Sanitize() 清除与选择性作者移除，并提供检查和验证步骤。