These warnings are irrelevant. Here is code which does not produce warnings:
PdfMemDocument doc;
for(int i = 0; i < 66; i++)
{
char name[10];
sprintf(name, "%02i", i);
doc.AddNamedDestination(PdfDestination(doc.GetObjects().CreateObject(
PdfArray()), &doc), name);
}
doc.SetWriteMode(ePdfWriteMode_Clean);
doc.Write("doc.pdf");
Also attached whole main.cpp file and patch.txt from "svn diff" output.
- PdfNameTreeNode( NULL, pChild1 ).SetLimits();
- PdfNameTreeNode( NULL, pChild2 ).SetLimits();
+ PdfNameTreeNode( m_pParent != NULL ? m_pParent : this, pChild1
).SetLimits();
+ PdfNameTreeNode( this, pChild2 ).SetLimits();
I tested this with latest (
http://svn.code.sf.net/p/podofo/code/podofo/trunk/) podofo revision 1890
where is still this bug.
As I probably wrote there is problem not passing parent nodes to these
constructors and then limits are not set in right way.
Pdf contents before patch:
7 0 obj
<<
/Limits [ (00) (65) ] *<- should be [(00) (32)]*
/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, here should b**e /Limits [ (33) (65) ]*
/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 ]
>>
Why is this not right is clear from pdf specification about this "Limits"
key. This key is required here and first value should be the "smallest"
name (lexically) and second the "biggest" name within "Names". These names
are actually strings like suggests parentheses.
Here when pdf reader searches for name "50" it will look only in object 7
because limits are from "00" to "65", it will not find it here so decides
name "50" actually does not exists even it is in object 73.
*After patch:*
7 0 obj
<<
/Limits [ (00) (32) ]
/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 ]
>>
endobj
...
73 0 obj
<<
/Limits [ (33) (65) ]
/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 ]
>>
endobj
This looks much better. Limits are ok.
This is minimalistic code which does not produce 100% valid pdf because
there are no pages for example. But is simple to add one
using "doc.GetPagesTree()->CreatePage(...)".
It is also possible to create more complex real world example with some
outlines or links (with named destinations) to pages which well known pdf
reader cannot see due to bad limits and this is also how I found this bug,
so I created this minimalistic example to see actual bug and how patch
fixed it.
On Mon, Dec 18, 2017 at 9:20 AM, zyx <z...@gmx.us> wrote:
> On Sun, 2017-12-17 at 17:08 +0100, Michal Sudolsky wrote:
> > From code around seems it really does not depend what parent is here
> > set, I followed logic above and did it like this (this is all what I
> > changed):
> >
> > old:
> > > PdfNameTreeNode( NULL, pChild1 ).SetLimits();
> > > PdfNameTreeNode( NULL, pChild2 ).SetLimits();
> >
> > new:
> > > PdfNameTreeNode(m_pParent != NULL ? m_pParent : this,
> > > pChild1).SetLimits();
> > > PdfNameTreeNode(this, pChild2).SetLimits();
>
> Hi,
> just few things:
> a) you accidentally replied only to me, not to the list
> b) this is far from being a patch, you should attach it, because your
> HTML message body breaks patch in several ways (and even if it's not
> HTML message, I still prefer patches as attachments, which avoids
> issues with mail readers)
> c) that didn't change anything here, the resulting PDF is the same
> d) I guess you are aware that the code snippet you provided in
> the first email of this thread is generating warnings on console:
> "Unsupported object given to PdfDestination::Init of type
> DictionaryDone"
>
> Bye,
> zyx
>
Index: doc/PdfNamesTree.cpp
===================================================================
--- doc/PdfNamesTree.cpp (revision 1890)
+++ doc/PdfNamesTree.cpp (working copy)
@@ -315,8 +315,8 @@
// of the children first,
// because SetLimits( pParent )
// depends on the /Limits key of all its children!
- PdfNameTreeNode( NULL, pChild1 ).SetLimits();
- PdfNameTreeNode( NULL, pChild2 ).SetLimits();
+ PdfNameTreeNode( m_pParent != NULL ? m_pParent : this, pChild1
).SetLimits();
+ PdfNameTreeNode( this, pChild2 ).SetLimits();
// limits do only change if splitting name arrays
if( m_bHasKids )
#include "podofo/podofo.h"
using namespace PoDoFo;
int main(int argc, char *argv[])
{
PdfMemDocument doc;
for(int i = 0; i < 66; i++)
{
char name[10];
sprintf(name, "%02i", i);
doc.AddNamedDestination(PdfDestination(doc.GetObjects().CreateObject(PdfArray()), &doc), name);
}
doc.SetWriteMode(ePdfWriteMode_Clean);
doc.Write("doc.pdf");
return 0;
}
------------------------------------------------------------------------------
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
