Not sure whether this is known bug but I think if yes then it would be
fixed long ago. When adding more than 65 entries in name tree then "Limits"
keys are wrongly set. Acrobat will not forgive that, it will not see all
names. Example code:


PdfMemDocument doc;
> for(int i = 0; i < 66; i++)
> {
> char name[10];
> sprintf(name, "%02i", i);
> doc.AddNamedDestination(PdfDestination(new PdfObject(), &doc), name);
> }
> doc.SetWriteMode(ePdfWriteMode_Clean);
> doc.Write("doc.pdf");


Results (acrobat thinks in object 7 are all names up to 65 so it will not
check other nodes for names 33 to 65 even if in object 73 would be right
limits):

7 0 obj

<<

/Limits [ (00) (65) ]          *<- should be [(00) (39)]*

/Names [ (00) 4 0 R (01) 8 0 R (02) 9 0 R (03) 10 0 R (04) 11 0 R

(05) 12 0 R (06) 13 0 R (07) 14 0 R (08) 15 0 R (09) 16 0 R

(10) 17 0 R (11) 18 0 R (12) 19 0 R (13) 20 0 R (14) 21 0 R

(15) 22 0 R (16) 23 0 R (17) 24 0 R (18) 25 0 R (19) 26 0 R

(20) 27 0 R (21) 28 0 R (22) 29 0 R (23) 30 0 R (24) 31 0 R

(25) 32 0 R (26) 33 0 R (27) 34 0 R (28) 35 0 R (29) 36 0 R

(30) 37 0 R (31) 38 0 R (32) 39 0 R ]

>>

...

73 0 obj

<<                      *<- here missing but Limits key is required by pdf
spec*

/Names [ (33) 40 0 R (34) 41 0 R (35) 42 0 R (36) 43 0 R (37) 44 0 R

(38) 45 0 R (39) 46 0 R (40) 47 0 R (41) 48 0 R (42) 49 0 R

(43) 50 0 R (44) 51 0 R (45) 52 0 R (46) 53 0 R (47) 54 0 R

(48) 55 0 R (49) 56 0 R (50) 57 0 R (51) 58 0 R (52) 59 0 R

(53) 60 0 R (54) 61 0 R (55) 62 0 R (56) 63 0 R (57) 64 0 R

(58) 65 0 R (59) 66 0 R (60) 67 0 R (61) 68 0 R (62) 69 0 R

(63) 70 0 R (64) 71 0 R (65) 72 0 R ]

>>


In PdfNamesTree.cpp in function "bool PdfNameTreeNode::Rebalance()":


        // Important is to the the limits
>         // of the children first,
>         // because SetLimits( pParent )
>         // depends on the /Limits key of all its children!
>         PdfNameTreeNode( NULL, pChild1 ).SetLimits();
>         PdfNameTreeNode( NULL, pChild2 ).SetLimits();


Where:

    PdfNameTreeNode( PdfNameTreeNode* pParent, PdfObject* pObject )
>         : m_pParent( pParent ), m_pObject( pObject )


Function "Rebalance" will split node when is added 66th name, these two
lines above should correct limits, but when parent is NULL then this
function is basically no-op, in "void PdfNameTreeNode::SetLimits() ":

    if( m_pParent )
>     {
>         // Root node is not allowed to have a limits key!
>         this->GetObject()->GetDictionary().AddKey("Limits", limits );
>     }


So PdfNameTreeNode constructor should be called with non-NULL pParent to
fix this.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Podofo-users mailing list
Podofo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/podofo-users

Reply via email to