iText7.1.14 CopyPagesTo复制PDF后/Kids数组为空致交互失效

• 业务场景：处理一批内嵌带JavaScript导航交互功能的PDF Widget注解文档，使用iText 7.1.14的PdfDocument.CopyPagesTo执行合并、单页复制操作时，输出文档的所有交互功能完全失效。
• 初步定位：通过RUPS工具分析发现，iText生成的输出文档中，原表单字段父字典的/Kids数组为空，不符合PDF Reference 1.7中“父字段字典的/Kids数组需指向其下属所有子字段”的规范要求。
• 问题代码位置：定位到iText中负责重建表单字段父子关联的方法PdfPage.RebuildFormFieldParent，其原有逻辑存在缺陷。

iText原有问题代码片段 #

private void RebuildFormFieldParent(PdfDictionary field, PdfDictionary newField, PdfDocument toDocument) {
    if (newField.ContainsKey(PdfName.Parent)) {
        return;
    }
    PdfDictionary oldParent = field.GetAsDictionary(PdfName.Parent);
    if (oldParent != null) {
        PdfDictionary newParent = oldParent.CopyTo(toDocument, JavaUtil.ArraysAsList(PdfName.P, PdfName.Kids, PdfName.Parent), false);
        if (newParent.IsFlushed()) {
            newParent = oldParent.CopyTo(toDocument, JavaUtil.ArraysAsList(PdfName.P, PdfName.Kids, PdfName.Parent), true);
        }
        RebuildFormFieldParent(oldParent, newParent, toDocument);
/**** 原有问题逻辑 *****/
        PdfArray kids = newParent.GetAsArray(PdfName.Kids);
        if (kids == null) {
            newParent.Put(PdfName.Kids, new PdfArray());
        }
/**********************/
        newField.Put(PdfName.Parent, newParent);
    }
}

缺陷原理：执行oldParent拷贝时，虽然将PdfName.Kids列入了需保留的字段列表，但此时目标文档中尚未完成对应子字段的对象拷贝，CopyTo过程无法正确解析原Kids数组中的间接引用，最终生成的newParent中Kids字段为空。原代码判断Kids不存在时，会直接赋值一个空的PdfArray，彻底丢失原有父子字段的关联关系，导致PDF阅读器无法顺着父字段索引找到对应的Widget注解，交互功能失效。

自定义临时修复方案 #

private void MyRebuildFormFieldParent(PdfDictionary field, PdfDictionary newField, PdfDocument toDocument)
{
    if (newField.ContainsKey(PdfName.Parent))
    {
        return;
    }
    PdfDictionary oldParent = field.GetAsDictionary(PdfName.Parent);
    if (oldParent != null)
    {
        PdfDictionary newParent = oldParent.CopyTo(toDocument, JavaUtil.ArraysAsList(PdfName.P, PdfName.Kids, PdfName.Parent), false);
        if (newParent.IsFlushed())
        {
            newParent = oldParent.CopyTo(toDocument, JavaUtil.ArraysAsList(PdfName.P, PdfName.Kids, PdfName.Parent), true);
        }
        RebuildFormFieldParent(oldParent, newParent, toDocument);
/**** 自定义修改逻辑 *****/
        PdfArray kids = (PdfArray)(oldParent.GetAsArray(PdfName.Kids).CopyTo(toDocument, true));
        if (kids == null)
        {
            newParent.Put(PdfName.Kids, new PdfArray());
        }
        else
        {
            newParent.Put(PdfName.Kids, kids);
        }
/**********************/
        newField.Put(PdfName.Parent, newParent);
    }
}

测试效果：替换上述逻辑后，通过RUPS验证输出文档的/Kids数组内容符合预期，复制后的文档交互功能与原文档一致。但存在兼容性问题：开启SmartCopy模式时会抛出SmartModePdfObjectsSerializer.SelfReferenceException，触发原因暂不明确。

最终验证结论 #

• 该问题属于iText本身的功能Bug：原输入PDF完全符合PDF 1.7规范，父字段下的/Kids数组为合法有效的子字段引用结构，不存在格式不合规的问题。
• 自定义修复方案不具备通用性：直接从原文档全量拷贝/Kids数组的实现，仅能在关闭SmartCopy的场景下工作。SmartCopy模式下iText会对重复对象做去重、引用映射优化，直接全量拷贝原Kids数组会导致引用关系自循环，触发自引用异常，无法适配SmartCopy的对象序列化规则。
• 合理的修复方向：iText官方需在重建表单字段层级时，将当前被复制的子字段在目标文档中对应的新引用，主动追加到对应层级父节点的/Kids数组中，而非因为初始拷贝拿不到有效引用就直接新建空数组。

内容的提问来源于stack exchange，提问作者Zarko Mocnik