ID/IDREF isn't exactly the same as indirect objects in COS. When you're parsing an XML document, ID/IDREF are just attributes like any other that get added to t

ID/IDREF isn't exactly the same as indirect objects in COS. When you're parsing an XML document, ID/IDREF are just attributes like any other that get added to the DOM, and then application code can dereference them later if it wants. In COS, indirect objects are part of the serialisation format and the parser needs to understand them and dereference them in order to be able to parse the file. For example, the COS "stream" object type is serialised as a settings dictionary, followed by the 'stream' keyword, the stream data, and the 'endstream' keyword. But what happens when the stream happens to contain the bytes 'endstream'? Well, the settings dictionary has a "Length" key that tells you how long the stream is, without you having to scan for the 'endstream' keyword. However, because most streams are compressed and compression makes it difficult to guess in advance exactly what the compressed size willl be, COS allows you to make the Length key an indirect reference to an integer defined later in the file. Like so: << % Here, the value associated with the Length key is % indirect object 42 revision 0. /Length 42 0 R /Filter /FlateDecode >> stream ...compressed data goes here... endstream % And now we define object 42 revision 0 42 0 obj 12345 endobj So, the parser needs to know the length of the compressed stream in order to parse it, but it needs to have parsed the compressed stream in order to get to the length data. The way out of this catch-22 is the object index at the end of the file, which gives you the index and location of each indirect object. A COS parser needs to start at the end of the file and load all the indirect objects, cache them, then go back to the beginning and stitch them into the deserialised object graph as they're referenced.