XRef stream vs xref

That didn't take long! I've been urged to compromise on legacy features already.

Members of the PDF/A camp, including one of my software engineers (Sergey), are concerned that dropping the old style xref tables means that no PDF/A-1 file can possibly be PDF/D compliant.  I was looking forward with the hope that PDF/A-2 support would be good enough but they disagree.

So, I've decided to take a step back and allow old style xref tables to exist in PDF/D but with plenty of constraints:

• only a single xref table (no Prev field in Trailer)
  
• no hybrid files (no XRefStm in trailer)
  
• no deleted objects (no f type in the xref table except for the first entry)
  
• generation numbers always zero
• only one section (implies consecutive object numbers starting at 1)
  

These simplifications mean that the end of the PDF file will always look like some variant of this:

xref

0 4

0000000000 65535 f 

0000000009 00000 n 

0000000122 00000 n 

0000000175 00000 n 

trailer

<<

  /Size 4

  /Root 2 0 R

>>

startxref

226

%%EOF

The other valid PDF/D entries in the Trailer are ID, Info and Encrypt.

As with my earlier PDF/D constraints, incremental updates and the dead objects that come with them are eliminated. So is linearization.

There you have it: the minimum required functionality of old style xref tables to make it possible for PDF/A-1 files to be PDF/D compliant.