Content

• Overview
• Usage by Topic
  • Setup
    • Installation
    • Initialization
    • Connections & Projects
  • Development
    • Hello World
    • Document Access
    • Concurrency
    • Logging
    • Document Markers
    • Observer
    • W2ML Manipulation
    • Loadtest Package
• Development by Task
  • Open Documents
  • Save Documents
  • Close Documents
  • Execute Scripts
  • Create and get PDFs
  • Get Previews (DocumentMetadata Part I)
  • Document Structure (DocumentMetadata Part II)
  • Build
  • Place Templates
• API Documentation

Overview

 

Idea

The Java Rendering Library was originally developed as a Java frontend for the priint pdf renderer. Purpose was easier integration of the pdf renderer in any Java application.

First Approach

For this, we compiled the command line pdf renderer application as a shared library plus some library export functions plus a couple of Java classes to access these functions via JNI.

This allows to access comet pdf functionalities directly in Java, in the same process, with almost no communication overhead. This also turns the pdf renderer into a stateful application: we can keep certain data in memory, while the Java host application is running, e.g. connection data and project configuration, font mappings, documents just being processed etc.

This again allows more specific access to rendering functionalities: we can run a series of "small" commands on a document without the overhead of loading the renderer application each time, connecting, parsing the W2ML data, processing, writing results and cleaning up. Renderer instances can also be initialized and wait in a hot standby mode to be quickly available for rendering requests on any time.

Finally, the direct integration in Java allows better error tracking and handling. There is no need anymore to track external processes, read stdout or stderr or evaluate program and shell exit codes. All failures are translated and re-thrown as Java Exceptions, so errors can easily be handled "the Java way".

Integration of InDesign® Server

Next step was to achieve the same easy-to-integrate Java interface for InDesign® Server. Until now, InDesign® Server could only be controlled via batch processing or using the common Adobe® Scripting DOM or accessing the interface provided by the PublishingServer / CometServer, which involves a couple of further system dependencies.

This led to the first refactoring iteration by seperating renderer specific code from core code and interfaces applicable for all kind of renderers. The formerly monolithic library PdfRendererLib.jar was split into a the priint-renderer-core, priint-renderer-pdf and priint-renderer-ids libraries.

Though the priint pdf renderer and InDesign® Server are currently the only available implementations, the library desing allows integrating of other renderers or variants as well.

Limitations by Design

The Java Rendering Library library is designed to work in any Java environment: there are no dependencies to PublishingServer, PubServerSDK, any Document Management system etc.

The library does not contain any solution for session management, database or project configuration access, locking or unlocking documents, accessing media and assets, use management, authorization management or whatever.

Limitations by Architecture

Particular renderer implementations involve limitations specific to this renderer. Currently, the following limitations applies for the priint pdf renderer:
The pdf renderer is a single threaded application. Parallel processing with pdf renderer means to start one distinct process per thread. This can partly be simulated by loading the shared renderer library several times in Java - which only works, if they are indeed different and provide differently named library functions. Therefore, if we want to run n parallel rendering processes in Java, we must compile and install n libraries. Since the native libraries are rather big (~20MB Windows version and ~100MB Linux or Mac version), we decided to build the Java and native library for 4 parallel rendering processes.

This means: 4 threads can run fully parallel. More Java threads can run parallel, but they require synchronisation and may be blocked eventually, if all renderer instances are currently occupied by other threads. See the Concurrency section for details.

Status and Outlook

After a second refactoring iteration in the beginning of 2022, the libraries are in useable and deliverable state. Functionality is still limited and not all use cases may be covered by the existing functionality. So, further development and changes will focus on functional improvements. The basic library design and core interfaces can be regarded as "stable".