# Product specifications
Product is the core of Mission Control and basis for every process inside the production part of the Zaikio platform. Without the basic product specification no planning or manufacturing can be done.
# Definition of the term product
Every time something is manufactured inside a print shop, we call that something a product. If a printer has 50 orders, with 10 line items each, that would be 500 products. We also use the terms product and product specifications synonymously.
Our understanding of product is similar to what other systems may already call products, however some call it jobs, others call it runs.
Some other systems might say product, when they mean product templates. Mission Control however does not store product templates, so every time something is to be manufactured a new product has to be created. Look at it as if Mission Control is just "living in the moment". We don't care how something came into existence, we simply expect to receive a new product specification every time we are supposed to build something.
# Sources of products
Product specifications come into Mission Control from various sources such as web2print software, MIS systems, workflow automation tools and many others.
Other connected software then operates on those products through the Mission Control API. So if you're not a developer of the aforementioned kinds of software you might never need to create a product inside Mission Control, you will however use and enrich the data provided to you. On the other hand if you are a developer of say a web2print software you might just upload your product specification here and call it a day.
# Required level of semantic accessibility
There are several levels of semantic accessibility regarding production specifications out there. To allow a truly seamless workflow into the future we aim for the highest semantics possible, which includes information about product parts including CAD-style layout descriptions, finishing, artwork, colours and desired substrates. Just providing a product name and a page number will no longer cut it.
# Separation of product specification and production specification
It is very important to understand the Mission Control makes a clear cut distinction between the specification of a product and the specification of its production. Our main interest in the beginning of the process is to understand the product by itself, without any details about its production, unless such details are required to ensure a certain outcome. For example you do not need to select a substrate, but need to provide boundaries in which the production process might be allowed to select the substrate at a later time. Another example would be content sections with many folded pages. For Mission Control it is unimportant how and even if those pages are folded when looking at the product specification in the beginning. These decisions are up to the connected apps that generate the production information later on. However if a certain fold is required to ensure the product is made in the right way, say for a zig-zag folded flyer, then that information needs to be provided in the specification (here in the part's layout) as well.
# Object graph
┌─────────────┐ │ Products │ └─────────────┘ │ │ ┌─────────────┐ │ │ Parts │ ├─▶│[with layout]│ │ └─────────────┘ │ │ │ │ ┌─────────────┐ │ ├──▶│ Substrate │ │ │ └─────────────┘ │ │ ┌─────────────┐ │ ├──▶│ Colors │ │ │ └─────────────┘ │ │ ┌─────────────┐ │ ├──▶│ Finishings │ │ │ └─────────────┘ │ │ │ │ │ │ ┌─────────────┐ │ │ ├─▶│Raw Materials│ │ │ │ └─────────────┘ │ │ │ ┌──────────────────────┐ │ └──────────┴─▶│ Artwork References │ │ └──────────────────────┘ │ │ │ ┌──────────────────────┐ │ │ │ Artwork Actions │◀─┤ │ └──────────────────────┘ │ │ ┌──────────────────────┐ │ │ │ Artwork Remarks │◀─┘ │ └──────────────────────┘ │ │ ┌─────────────┐ ├─▶│ Packagings │ │ └─────────────┘ │ ┌─────────────┐ ├─▶│ Assignments │ │ └─────────────┘ │ │ │ │ │ │ │ │ ┌─────────────┐ │ └─▶│Zaikio/Person│ │ └─────────────┘ │ ┌──────────────────────┐ └▶│ Product Actions │ └──────────────────────┘
# Products and their parts
Products are made out of one or many parts. Thus parts are segments of a product, which are manufactured independently and are ultimately put together at various stages during the production process to form a final product.
Each part has an individual layout, colour configuration and substrate information. This also dictates that, as soon as two different colour configurations or substrates are used within the same product, the product must be split up into several parts - which exactly mirrors the production reality of such a product.
Mission Control understands what product you want to make through the
kind attribute. This attribute also defines which parts a product can or must have. There are simple products, like a business card, which only has one part, the "card" itself. At the other end of the spectrum, we have products like books which can have many parts, such as the jacket, case, endpapers and one or many content parts.
For some products, some parts can be repeated multiple times, while others can only exist once. Also, some parts must be present, while others might be optional. Mission Control knows this and will produce error messages if misconfigured products are sent into production. Please refer to the Product Parts overview for a list of the supported products and their required and optional parts.
We chose to be semantically specific, to ensure a broad understanding of the product in question across the entire process. If you want to create a product that is not supported by Mission Control at this time, please contact us, and we will add support.
# Colours and substrates
Each part specifies the colours required to produce it. When we talk about colours, we have a two-step approach to identifying them: the colour system (CMYK, Pantone, HKS) and the colour name inside that system.
Each colour is attached to either the
back of a page and a
coverage can be supplied to allow cost calculation and production optimisation.
Just like colour information each part also contains information about the desired substrate. We call it "desired" because this data expresses the wish of the customer in regards to the substrate. Picking a specific substrate is thus not required to enter a production state. The customer's wishes could also be less specific, for example just requiring a category of substrate and a certain paper weight. The actual decision about the substrate can then be deferred to production planning. Naturally it is also possible to require a specific substrate right from the start.
The layout of the part describes its physical appearance in CAD-style language. Since the requirements for such a description vary with the product kind we currently support two description methods for layouts:
- the box based layout (for commercial, books, etc.) and
- the path based layout (for packaging and labels).
Since the latter is much more flexible but also more complex we opted to support two description styles, so software developers can pick the one they truly need for the products their software is supposed to operate with.
Both models support various units of measurement (like pt, cm, mm, inches, pixel, pica, etc.). The unit has to be defined globally per layout, so mixing inside a single layout is not possible. The software that operates on the layouts is required to understand the unit and perform appropriate conversions when necessary.
# The box layout
The box layout is loosely modelled on the CSS box model [LINK] and describes the contents of a part as a collection of boxes. Boxes can represent sheets, roll segments, folds, pages, spines, flaps, finishings, and so on.
Boxes are hierarchical and thus may be nested inside one another. They feature a position based on a top-left coordinate system as well as dimensions. Additional information like bleeds and unprinted borders are supported per box, as well as links to the artwork.
Please check out the box layout model guide for further information about the box model.
# The path layout
The path layout model is similar to the box layout model, but instead of square boxes it uses bezier paths in order to describe the objects. Thus this model is much more flexible regarding the pictured parts, but also more complex. This model is currently in development, please check back here for any news.
Mission Control allows you to store references to artwork files attached to
Finishings. We do not store the artwork itself, only a reference URL and meta information regarding the file. The file might reside in the cloud or on premise, but generally should be accessible to all connected apps to allow seamless operation.
On top of meta information regarding a file, like
kind, we also support storing information about current
ArtworkActions that are performed on the file, such as preflight, colour corrections etc. You can provide progress information and in the form of
ArtworkRemarks further information about this process. This information can be used by other apps to determine when they should perform their operations on the artwork and also a means of information the user in the Mission Control UI about what's going on.
# Finishings and their applications
Nearly no printed product leaves the factory without finishings being applied to it. In Mission Control's language a finishing is everything that is added to the product after printing. Cutting and folding are thus not considered finishings and are part of the production information, not the product specification [see above]. Finishings might be
saddle_stitching, and so on. A full list is available here [LINK].
When finishings are created in the context of a part they will be automatically applied to said part. However some finishings might be applied to multiple parts (case making for example encompasses the case and the contents of a book). To support this, Mission Control uses
FinishingApplications. With finishing applications you can connect a finishing to a part or many parts.
Each finishing as a set of attributes that further describes it. These attributes may vary from finishing to finishing and can be looked up in the Finishing API reference [LINK].
Additionally, artwork can be attached to finishings as well. These might be PDF or SVG files containing lamination information or paths that describe a die cast, amongst others.
# Number of copies
How many copies of a certain product needs to be produced can be specified through the
quantity attribute. There are also
acceptable_quantity_underrun attributes to specify a corridor in which the actual amount of copies might lie.