#50 Tree class, collapsing root bug

v1.0_(example)
open
5
2013-05-17
2013-05-17
Andreas Pinter
No

Hi Stefano,

I noticed another little bug in the Tree class, when finding a specific key.
Im currently removing a bunch of named destinations with the following code fragment:

for( keyName in list ) { Tree.Remove(keyName); }

That works fine until the Tree is so empty, that PdfClown is collapsing it down to one single root node:

8 0 obj
<< /Kids [(F)15 0 R(G1012)16 0 R(G1013)17 0 R(G1014)18 0 R(G1017)19 0 R(G1019)20 0 R] >>
endobj

With that node as "root" the searching for the remaining keys does not work any more, since Clown reads this as a "intermediate node" and expects /Limits, which aren't there.

From the PDFSpec 1.6 for the /Kids Field (TABLE 3.32):

(Root and intermediate nodes only; required in intermediate nodes; present in the root
node if and only if Names is not present) An array of indirect references to the immediate
children of this node. The children may be intermediate or leaf nodes.

I read this as if the above is invalid, since 'root' should only contain intermediate or leaf nodes, but those are already destinations. If I misread it and it is valid PDF, at least the check for "isIntermediate" should be extended since this is not an intermediate node, is it?

Greetings,
Andreas

Discussion

  • Andreas Pinter
    Andreas Pinter
    2013-05-17

    My current workaround does something similar as "UpdateNodeLimits".
    At the end of colapsing the root, I verify if it is the real root or not. If it is the real root the /Kids are changed to /Names. If it is not the real root, no change is needed sind the colapsed node was just changed from Leaf to Intermediate.

    // Root node?
    if (kidChildren.Parent == BaseDataObject)
    {
    kid[PdfName.Names] = kid[PdfName.Kids];
    kid.entries.Remove(PdfName.Kids);
    }

    Greetings,
    Andreas