CODEWITHSUNDEEP
pdfitext7
Biggert
Biggert

Reputation: 278

iText does not copy resources dictionary from /Pages for a PDF Document

I have a Pdf which has Fonts stored in the /Resources dictionary at the /Pages level of the Document in order for them to be re-used for every page. This seems to achieve 2 things: proper display of course but also a smaller file size. When using iText to copy pages from this Pdf, I've noticed that, regardless of using higher level or lower level functions (such as PdfPage's copyTo or copyFormAsXObject), the resulting Pdf does not have the characteristic - the Resources are instead stored at each individual page.

Is there a particular reason why this isn't adhered to when doing page copying?

Furthermore, I attempted to do this myself but there doesn't appear to be any way of putting the Resources at the Pages for the document. I can do it for individual pages with the .put method on PdfPages but, for PdfDocument, there doesn't seem to be an equivalent. Is there a way I can create a PdfDocument with this structure using iText?

Upvotes: 2

Views: 1143

Answers (1)

Michaël Demey
Michaël Demey

Reputation: 1577

You don't need to worry about bloating your PDF. Resources are added as an indirect object to your resources dictionary. This means that the resources dictionary will keep a reference to the actual resource object and it doesn't need to embed it into the dictionary. Here's the /Pages entry of a PDF:

3 0 obj
<<
    /Type /Pages
    /Count 3
    /Kids [5 0 R 13 0 R 23 0 R ]
    /Resources <<
        /Font <<
            /FAAAAH 7 0 R
            /FAAABG 16 0 R
        >>
        /ExtGState <<
            /GS1 15 0 R
            /GS2 21 0 R
            /GS3 25 0 R
        >>
    >>
>>

The "/FAAAAH 7 0 R" line means that font FAAAAH is object # 7. As you can see the resources dictionary only keeps a reference (7 0 R) to the font object. The actual font object resides somewhere else in the PDF. Every PDF reader and parser knows how to access object # 7.

If you're experiencing bloating when copying or merging, then the PDF probably contains the font twice instead of only once and having two references to it. The location of the /Resources doesn't have any relevance to the bloating of the file, it's what's inside the PDF that adds to the bloat.

You can counter this in iText by running the PdfWriter in smartmode:

pdfWriter.setSmartMode();

We'll look into why iText doesn't copy the inheritance.

Upvotes: 2

Related Questions