XREF table about printpdf

[fschutt]

This is not a valid PDF - whether it "works" depends on the PDF viewer you're using. The point of an xref table is so that the PDF reader doesn't have to scan through the entire file to see where the objects start and end. It might work in some viewers to omit the table, but I wouldn't rely on it - and it will certainly degrade performance of reading the PDF because now the reader has to scan through the entire document to find where the objects are. According to the PDF spec the xref table is mandatory.

Also, I'm not an expert on this topic either - the wiki is just http://www.p2501.ch/pdf-howto/start translated to English. You could also try reading the PDF spec from Adobe or use a different tutorial such as https://brendanzagaeski.appspot.com/0005.html - I don't "know" whether it works, you need to test it in different viewers.

[fschutt]

No, each line in the table is 20 bytes long. The "50" says that one object starts a 50 bytes from the start of the file. Objects described by the xref table can be larger than 20 bytes, but the lines of the xref table are exactly 20 bytes: The string "0000000000 65535 f " is exactly 20 characters long.

As to how they are calculated, that depends on the implementation. I used lopdf for the low-level serialization, I didn't actually write any byte-tracking algorithm myself, but I can imagine that you simply serialize each indirect object to bytes, and the create the xref table by summing up the bytes of the individual objects.

[mahmoodn]

It seems that xref is not mandatory. The following code also works

%PDF-1.4
1 0 obj
<< /Type /Catalog /Pages 2 0 R >>
endobj
2 0 obj
<< /Kids [3 0 R] /Count 1 >>
endobj
3 0 obj
<< /Parent 2 0 R /Contents 4 0 R >>
endobj
4 0 obj
<< /Length 20 >>
stream
BT
/F1 40 Tf
100 600 Td
(Hello World!) Tj
ET
endstream
endobj
trailer
<< /Size 4 /Root 1 0 R >>
%%EOF

Is that correct?