Handling Images

In priint:cloud you have three main options to provide images to the rendering process:

• Publicly available image URLs (like the one in the example above). Images will be downloaded during rendering.
• Images as part of the comet xml project (aka 'static images')
• Images send together with the data.xml in a zip file as request body to the /renderpdf endpoint

Internet Images

Providing image URLs as part of the XML input data is the most obvious and commonly used variant. This has some consequences:

• Images must be available in public internet
• Images will probably be protected by some security method (BasicAuth, OAuth2, etc.)
• Images are downloaded by the mediaproxy. This requires some configuration. See Media Proxy Integration
• Image download can have a huge impact of the rendering time. Slow media asset server lead to slow PDF generation.

Images are sent as references within the content data - typically, relative or absolute URIs. During the PDF generation the URIs will be read from the source system. Actually, all images URIs are gated via a specialized internal component, the "mediaproxy".

If access to images is protected the mediaproxy must be configured as given in the connection configuration examples.

For re-occurring images caching can be activated and configured in mediaproxy. Cached images are separated by tenant and project.

/mediaproxy/config.ion

{
  "connections": [
    {
      "method": "GET",
      "url": "https://example.com/images/",
      "authentication": {
        "type": "ApiKey",
        "key": "API-KEY",
        "value": "7271d91c0d8e104bcc93c9f7af5626bbfae2c0295eced7d86985b90f639e8844"
      }
    }, {
      "method": "GET",
      "url": "https://www.mywebshop.biz/media"
    }
  ]
}

The example shows a config that allows ApiKey protected resources from domain example.com plus unprotected resources from a web shop.

If multiple connections are configured the best matching configuration will be selected (matching the url string from the start).

Static Images in the Comet XML Project

You may place images within the Comet XML Project file structure.

Static Images in the Directory Structure of Comet XML Project

comet/
└── images/
    └── mypic.png

These images can be referenced as local file resources within the comet scripts (py pr crpt). The above example image could be referenced as $COMETDATA/images/mypic.png in script code.

When to use "Static Images"

• for small pictures only
  • huge static images blow-up the project size and hence slow down loading times
• for pictures that are used very often
  • like icons, certification labels, etc.
• for pictures that do not change during project life-time
  • these pictures can be seen as variable parts of the templates

When NOT to use "Static Images"

• for data driven pictures
  • pictures that are tied to products
  • or are subject to change during project lifetime
• for large pictures
• for rarely used pictures

Images in Input Zip

The /renderpdf endpoint of the REST API supports sending data in a ZIP file. The ZIP can contain XML data as well as image files. These image files are available as local file resources during rendering.

The zip format allows you to send a self-sufficient data package to the rendering services so that the rendering process needs not to retrieve any further resources.

Images from Input Zip

├── data.xml
├── images/my.pic.png
└── drawings/my.graph.pdf

Comet users can retrieve the files within the zip using the GRID_DATA_DIR environment variable in Python or CScript.

See REST API Rendering for more information.

When to use "Images in Input Zip"?

• Media asset system is not reachable via public Internet (or is not stable)
• Retrieving images within the data agent is much faster than via remote access
• Collecting necessary images is an easy to define process in the data agent
• Image content changes rapidly between Job request and Job execution