The hierarchy of Timelines

This page applies to Harlequin v13.1r0 and later; and to Harlequin MultiRIP but not Harlequin Core

Timelines naturally form a hierarchy. So, when a timeline is created it can be defined with a parent -  another timeline reference. A timeline is a child of another timeline or an autonomous timeline in its own right. The reason for this hierarchy is that in a multi‐threaded and more especially a pipelined RIP, (in fact any program that has to deal with more than one thing at a time), you can have a number of distinct elements of the same type all of which will have their own lifetime.

The timeline system provides a method of unique identification which is retained even if the entity has ceased to exist, and if you did try to use it you would get a “safe” error result

The availability of a hierarchy allows things to be broken up or sub‐divided so that you can then have a single reference to a very specific item within a system.

There are API calls that, given a timeline reference, you can ask for a timeline in that hierarchy of a particular type. In the case of the RIP, with a timeline reference, you can ask for a core job timeline that is part of a hierarchy. This means you can have a reference to a very specific sub‐division, and if you are interested in the overall job, one call will give you the reference for that overall job.

Examples of things a timeline can represent are; a print job; the RIP skin's concept of a job; the RIP core's concept of a job; a font cartridge; a fuser unit or a print head.