Overview

You can use the priint:comet pdf renderer for rendering pages, exporting PDF documents, create previews and several more rendering tasks.
Connecting publishing server with priint:comet pdf renderer requires some additional setup steps, which are described in this document.

Installation hints for priint:pdf renderer

Requirements

These are the minimal versions required to use priint:pdf renderer with the publishing server:

Basic Installation

Please follow the installation instruction delivered with your priint:pdf renderer release. This contains detailed information about licensing, configuring fonts and pdf presets ("joboptions") and additional requirements.

For a quick test ater installation, you can just open a terminal or a command prompt, change into the installation directory and type

comet_pdf -s hello

If the basic installation works, this will generate a PDF welcome page and open the system default PDF viewer.

System privileges

Please make sure, that the Java Application Server user (service account or local system account) can access the priint:pdf renderer installation directory. Minimal requirement is read the directory content and run the comet_pdf.exe resp. comet_pdf programm.

Depending on the path configuration (see below), you may also have to grant write privileges on this directory (or subdirectories) to this user.

Connecting publishing server to priint:pdf renderer instances

To use the priint:pdf renderer with the publishing server, it first must be configured in the comet_admin database resp. priint:suite administration console.

During installation, you can choose whether to support priint:pdf renderer or not, and choose the number of instances, installation path etc. You can change this configuration later, however some of these settings can only be edited directly in the database and will require a server restart.

Basic configuration

The priint:pdf renderer instances need to connect back to the publishing server (actually to the Comet3 WebService provided by the CometBridge PubServer Plugin), this is a SOAP over HTTP connection.

The callback address and credentials can be configured in priint:suite > Administration > Preferences > AdminDB property.

Furthermore, you can configure some basic settings for all priint.pdf renderers connected to the publishing server.

Settings in this panel:

Note: the latter two settings will most probably be obsolete in the final 4.1 Release. Handling of heterogenous document types is currently being developed, in later versions this will not require any extra configuration.

Note II: by setting Check Renderer File Type to true and configuring both priint:pdf renderer and InDesignServer instances, you can process different document types on the same server at the same time. The alpha and beta Releases of the 4.1 version only support one document type - either InDesign® or W2ML - at the same time, so using different document types is an inofficial feature, which might help you in certain situation, but is not suppoerted by Werk II.

basic configuration

priint:pdf renderer configuration

There should be at least two preconfigured server entries in the priint:suite > Administration > Preferences > AdminDB property > Indesign servers node. Actually we do not configure physical servers here, but only server types (LOCAL, REMOTE). For PDF Renderer, we need a third entry with type PDFRENDERER.

You can check, which server types are configured in the indesignserver table in the comet_admin database (e.g. using MySQL Workbench, Microsoft SQL Server Management Studio or similar tools).

SELECT * FROM comet_admin.indesignserver;
should output something like
+----------+----------------+----------------+
| SERVERID | SERVERNAME     | SERVERPROTOCOL | 
+----------+----------------+----------------+
| 2        | Remote Server  | REMOTE         |
| 3        | Offline Server | COMETOFFLINE   |
| 4        | PDF Renderer   | PDFRENDERER    |
+----------+----------------+----------------+
If the PDFRENDERER entry is missing, add it, e.g. using this SQL statement:
INSERT INTO comet_admin.indesignserver (SERVERID, SERVERNAME, SERVERPROTOCOL) 
    VALUES (4, 'PDF Renderer', 'PDFRENDERER');
You must restart glassfish / publishing servers to see the changes.

server types

priint:pdf renderer instance configuration

By opening the PDFRENDERER server node, you should see instances configured for this server type (see screenshot).

server instances

If there are no or not enough instances, you have to add them to the comet_admin.indesignserverinstance table (e.g. using MySQL Workbench, Microsoft SQL Server Management Studio or similar tools).

SELECT * FROM comet_admin.indesignserverinstance;
should output something like
+------------+----------+--------------+-------------------+--------+-------
| INSTANCEID | SERVERID | INSTANCENAME | ENDPOINT          | ACTIVE | TYPEID ...
+------------+----------+--------------+-------------------+--------+-------
| 7          | 4        | Renderer_01  | local://C:\pdf_.. | 1      | 2      ...
| ...        |          |              |                   |        |        
+------------+----------+--------------+-------------------+--------+-------

To add an instance, type something like

INSERT INTO comet_admin.indesignserverinstance
  (INSTANCEID, SERVERID, INSTANCENAME, ENDPOINT, ACTIVE, TYPEID, LOGIN, PASSWORD)
     VALUES
  (8, 4, 'Renderer_02', 'local://C:\\pdf_renderer\\', 1, 2, '', '');

INSTANCEID must be unique (e.g. SELECT MAX(INSTANCEID) + 1)

SERVERID must be the ID of the PDFRENDERER entry in the indesignserver table.

INSTANCENAME must be unique (see path information above)

Once created, the priint:pdf renderer instances can be configured in the priint:suite administration console.

Settings for each instance are

Note: using dedicated credentials for each priint:pdf renderer instance can be very useful when tracking problems in the Glassfish / publishing server log file.

instance configuration

priint:pdf renderer instance type or purpose

To seperate long running tasks like generating pages from tasks, which require fast response times, priint:pdf renderer instances can be assigned to a certain type.

Which configuration best fits your requirements, depends on the usage scenario: the number of concurrent Whiteboard users, the kind of jobs executed in your system, the number and type of Java clients etc.
You should avoid instances of type MIXED, unless in small installations (only one or two InDesignServer instances) or for testing purposes.

Installation and configuration of remote pdf renderers

Connecting to remote priint:pdf renderers requires an additional server component. This is a very tiny WebService component delivered as an EJB jar file called CometPdfRemote.pdf.

Installation

The WebService component requires a Java EE 6 compliant application server. It's recommended using the same application server like for the PubServer installation.
At the time, this is the Glassfish 3.1.2 Java EE 6 reference implementation.

You can either

or If you install a blank Glassfish server, you have to copy the following libraries to the domain lib folder:

After installing the application server and additional domain libraries, deploy the CometPdfRemote.jar application (using the web administration UI or autodeploy folder).

Configuration

A couple of system properties must be configurd, before you can connect to this pdf remote service.

To do so, open the application server administration UI and navigate to Configurations > server-config > System properties: server administration

At least the following two properties must be set:

There is no default value for these two properties. If either of these properties is undefined or empty, the CometPdfRemote service will refuse to work.

The following two properties are optional:

properties

Paths and folders

You must setup the following paths and folders to use the priint:pdf renderer

Cache Path

This path is used by the priint:pdf renderer to store temporary data (downloaded templates, actions etc.). The name of this folder is derived fromthe instance name and the base Working Directory (relative to the installation directory or absolute path), which you configure in the priint:suite administration panel (see screen shot below).

Directory layout, when using a relative Working Directory path (e.g. "var"):

<PDF renderer Installation directory>
    + var
      + InstanceName
         + XCache

Directory layout, when using a relative Working Directory path (e.g. "D:\data\pdf_renderer\"):

D:\data\pdf_renderer\
    + var
      + InstanceName
         + XCache

InstanceName, in both cases, is the name of this priint:pdf renderer instance as configured in the priint:suite adminstration panel, see Section 3.3 (pdf renderer instance configuration) above. Therefore it is mandatory, that the instance name is unique, otherwise cache and other output of several instances might get mixed up.

Requirements

Configuration: priint:suite administration panel, see description and screenshot above.
Example: var or D:\data\pdf_renderer\

Comet Log

This is the file comet log messages are written to. The name of this file is derived from the instance name and the base Working Directory (relative to the installation directory or absolute path), which you configure in the priint:suite administration panel (see screen shot below).

Directory layout, when using a relative Working Directory path (e.g. "var"):

<PDF renderer Installation directory>
    + var
      + InstanceName
         + comet.log

Directory layout, when using a relative Working Directory path (e.g. "D:\data\pdf_renderer\"):

D:\data\pdf_renderer\
    + var
      + InstanceName
         + comet.log

InstanceName, in both cases, is the name of this priint:pdf renderer instance as configured in the priint:suite adminstration panel, see Section 3.3 (configuring pdf renderer instances) above. Therefore it is mandatory, that the instance name is unique, otherwise log messages of several instances might get mixed up.

Requirements

Configuration: priint:suite administration panel, see description and screenshot above.
Example: var or D:\data\pdf_renderer\

Comet API Log

This is the file comet API log messages are written to. The name of this file is derived from the instance name and the base Working Directory (relative to the installation directory or absolute path), which you configure in the priint:suite administration panel (see screen shot below).

Directory layout, when using a relative Working Directory path (e.g. "var"):

<PDF renderer Installation directory>
    + var
      + InstanceName
         + api.log

Directory layout, when using a relative Working Directory path (e.g. "D:\data\pdf_renderer\"):

D:\data\pdf_renderer\
    + var
      + InstanceName
         + api.log

InstanceName, in both cases, is the name of this priint:pdf renderer instance as configured in the priint:suite adminstration panel, see Section 3.3 (configuring pdf renderer instances) above. Therefore it is mandatory, that the instance name is unique, otherwise log messages of several instances might get mixed up.

Requirements

Configuration: priint:suite administration panel, see description and screenshot above.
Example: var or D:\data\pdf_renderer\

Temporary Session Files

This is the folder, temporary session data is written to and read from. Typically this is a network mount, because other components (publishing server / CometServer) access this folder too.
Requirements

Configuration: priint:suite adminstration, variable tmpPath. See screenshot below. Don't forget to click the "save" button after changing this value!
Example: \\Shared\publishing_server\tmp

Document Files

This is the folder, documents (e.g. publication documents) are written to and read from. Typically this is a network mount, because other components (publishing server / CometServer) access this folder too.
Requirements

Configuration: priint:suite adminstration, variable documentRoot. See screenshot below. Don't forget to click the "save" button after changing this value!
Example: \\Shared\publishing_server\documents

 

Screenshot Temporary Session Files and Document Files configuration:

priint:suite administration

Monitoring priint:pdf renderer instances

Under priint:suite > Administration > InDesign® instances you find a list of configured InDesignServer instances and information about the current status, whether it's currently processing a job or not, the number of opened documents on this instance, usage statistics etc. (again: for historical reasons this is still called InDesign® instances in the UI, though this view refers to all type of renderers).

Double-clicking an entry opens a separate panel, which shows the documents currently opened on this instance.

monitor

Example configurations

This section describes some typical path configurations for PubServer / priint:pdf renderer running on the same or on dedicated hosts.
Please note:

Publishing server and priint:pdf renderer on the same physical machine (Windows)

If document or temporary files are located on a network drive, assign the target volume to a drive letter (e.g. Z:) before and use local paths for the configuration settings.

Publishing server and priint:pdf renderer on dedicated Windows machines

Publishing server on Windows, priint:pdf renderer on Mac

  1. Document and temporary files on the Windows host If document or temporary files are located on a network drive, assign the target volume to a drive letter (e.g. Z:) before and use local paths for the configuration settings.
    • mount this volume or folder on the Mac server
    • create a symbolic link on root level to respect the folder hierarchy:
      sudo ln -s /Volumes/pubserver /pubserver
      
  2. Document and temporary files on the Mac host
    • mount and assign the volume for Document Files to a drive letter on the publishing server host, e.g. F:
    • mount and assign the volume for temporary session files to a drive letter on the publishing server host, e.g. T:
    • set documentRootPath and tmpPath in the priint:suite administration using the same drive letters (e.g. F:\\documents\ resp. T:\\tempfiles\, see Section 5.5 Document Files and Section 5.4 Temporary Session Files)
    • create symbolic links on root level to respect the folder hierarchy:
      sudo ln -s /Volumes/Data/appserver/documents /documents
      sudo ln -s /Volumes/Data/appserver/tempfiles /tempfiles