A document object contains one or more page objects.
A page object contains one or more layer objects.
A layer object contains one or more graphic objects.
Eh, sort of.
A PDF must contain exactly one /Catalog. In the trailer, the /Catalog object reference must be given as the /Root dictionary entry.
A /Catalog contains an ordered array of object references to /Page objects, identified by the /Pages dictionary entry.
A /Page object contains a back reference to its enclosing catalog object, a description of the extent of physical and logical media (e.g., for bleeds), a /Contents object that may contain page-global streams such as initial graphics state, and a /Resources object that expresses a list of procedure sets to be applied, in order, to their subordinate objects, in order.
A graphic object could be an image, text, a font or pretty much anything you can put in a PDF.
Romney's PDF consists of a single /Page and a single /ProcSet referring to a single /XObject /Image encoded in telefacsimile. It is rendered using /PDF (for the initial page graphics state), and /ImageB decoders for grayscale images.
Obama's PDF consists of a single /Page and a single /ProcSet invoking /PDF, /ImageC and /ImageB renderers, and having 9 subordinate pixel-map or bitmap objects.
Its a hierarchy of objects. But they are all treated as objects, just with different properties.
At the file level there are a few control data structures and a flat list of objects -- "flat" meaning that there is no hierarchy visible in the lexical structure of the file. Hierarchy enforced by the PDF standard is as I've described above.
Optional-content grouping emerged in PDF 1.6 and was further refined in 1.7, but has no bearing on Obama's PDF (version 1.3) which provides only the hierarchy I describe in my previous post. Objects of type /OC can express a finer-grained logical relationship among objects, but they are still typically only hints to viewing, such as "Do I expand this object too if the user zooms in?" or the aggregation of visibility control (cf.
op. cit., 6 ed. pp. 364ff).
This is still not analogous to content-producer layers or groupings because /OC and /OCG structures are not mutually exclusive; an object can be in more than one optional-content grouping. Or it can be in none. In Photoshop, Illustrator, etc. an object is in exactly one layer. Even if the document has only one layer and all the objects are in in, the Layer is a first-class data structure in all their formats. PDF optional-content groupings are just that: optional. If no groupings appear, there are simply no groupings implied, except for the practicality of rendering. You can think of it as a "default layer," but it's more accurate to think of it as "no layers -- everything in one big pile."
Acrobat 4 allowed one to paste an object into a PDF and retained it as a separate layer. Acrobat 6 onwards merged your paste into an existing layer.
Acrobat 9 does the same. You must first create an empty layer and then paste content into it. That layering of content is not interpretable or visible in other program such as Illustrator or
evince. Whether by /PieceInfo or by /OC, the interpretation of layered content remains highly inconsistent. Hence Adobe's advice to flatten the file if you experience rendering difficulty.
I am sure other developers would criticise my structures for similar reasons.
And vice versa. One may opt to have clean exportation code, for example, that produces baroque PDF hierarchies rather than complex code to produce optimal PDFs.
Illustrator, haha, all hell is out for breakfast.
Adobe goes to great lengths to posture its creative products as a integrated suite. As a matter of fact, however, the Illustrator team has always been sort of a law unto themselves. The fact that you can create a new /OCG in Acrobat, paste content into it, and have it fail to be recognized as a layer in Illustrator is, sadly, par for the course.