comet for priint:cloud
priint:cloud uses comet:pdf renderer (aka comet_pdf) to render PDF documents from XML input data and project configuration.
comet:pdf Renderer
comet:pdf renderer is a commercial standalone software developed by WERK II. This software generates PDF files based on priint comet technology. Comet:pdf renderer is compatible with the comet InDesign solution and available for Windows, Mac and Linux (see https://www.priint.com).
For priint:cloud the standalone comet:pdf renderer is used in a containerized environment and orchestrated by Kubernetes.
As a consequence some restrictions apply to comet_pdf project configurations.
For the current documentation we assume that you are already familiar with comet technologies and with the traditional comet xml project flow.
A complete documentation of comet technologies including the renderer can be found here
Differences - cloud vs standalone
Working via REST APIs feels and is different to traditional standalone (or offline) projects started from the command line.
For comet_pdf running in priint:cloud the following must be noted:
- comet_pdf is called indirectly via RESTful API
- comet_pdf is running in a Linux context
- stricter directory layout
- no direct control over command line arguments
- all input data (except images) for one PDF must be transmitted within a single XML file
- rendering is asynchronous
- artifacts (PDFs or log files) must be downloaded before they can be viewed
- retrieval of media assets via URLs is delegated to the 'mediaproxy' component of priint:cloud
- a single API call may trigger several comet_pdf runs (fanout mode)
- because of cloud overhead individual renderings are slightly slower than in standalone mode, but mass renderings are must faster due to horizontal scalability
- priint:cloud allows you to select between several versions of comet_pdf which are installed in parallel
Comet has a few configuration options to obtain product data such as connection to the Publishing Server Entity Manager or connection to the database or using comet via SOAP protocol. In priint:cloud we don’t use those options, because we want to encapsulate everything in one execution of the comet pdf renderer without and external data sources. We decided to use the comet XML variant as a rendering option in priint:cloud because this comet solution makes us independent of any external data source. Everything (except images) we need for one rendering process should be stored in one “product’s” XML file.
From the technical point of view, a single call of the priint:cloud rendering API (a RESTful service) may instantiate one or more rendering jobs. Those jobs are sent to the rendering queue. Each rendering worker is listening to the queue and may take a job with its product data (XML file) whenever it is presented. Information about the comet project is stored in the message. Based on this information, the worker downloads the correct comet XML project files from the internal repository. After that, the worker unpacks the project, downloads the correct version of the comet pdf renderer software, copies “products XML” and finally starts a rendering process.