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.

Requirements

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

Recommended minimum versions:

Installation Hints for priint:renderer

Basic Installation

Please follow the installation instruction delivered with your priint: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: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 priint:publishing server to priint:renderer Instances

To use the priint: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: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:renderer instances need to connect back to the publishing server (actually to the Comet3 WebService provided by the CometBridge priint:publishing server plug-in), 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 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: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 supported by Werk II.

basic configuration

priint: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 etc.), see screenshot below.
If for any reason these nodes do not exist in your installation, you have to edit the /pubserver/pluginconfig/com.priint.pubserver.preferences.InDesignServers/custom/InDesignServers.xml config file in the configs repository (using ISON Eclipse [Repository view]). This file should look like the following: 

<?xml version="1.0" encoding="UTF-8"?><con:PluginConfig xmlns:con="com.priint.pubserver.config.manager/20130620">
    <con:name>InDesignServers.xml</con:name>
    <con:type>InDesignServers</con:type>
    <con:description/>
    <con:custom>
        <cfg:InDesignServers xmlns:cfg="http://priint.com/pubserver.appserver.config/v1">
            <cfg:InDesignServers serverId="2">
                <cfg:serverName>Remote Server</cfg:serverName>
                <cfg:serverProtocol>REMOTE</cfg:serverProtocol>
            </cfg:InDesignServers>
            <cfg:InDesignServers serverId="3">
                <cfg:serverName>Offline Server</cfg:serverName>
                <cfg:serverProtocol>COMETOFFLINE</cfg:serverProtocol>
            </cfg:InDesignServers>
            <cfg:InDesignServers serverId="4">
                <cfg:serverName>PDF Renderer</cfg:serverName>
                <cfg:serverProtocol>PDFRENDERER</cfg:serverProtocol>
            </cfg:InDesignServers>
        </cfg:InDesignServers>
    </con:custom>
    <con:dependencies/>
    <con:instances/>
</con:PluginConfig>

If the configuration file or the entry for PDF renderer is missing, add the file respective add the lines marked in the example above to the file and restart the publishing server.

server types

Note: in future versions, configuration of PDF Renderer and PDF Renderer instances might also be supported by the installer..

priint: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 must add them to the /pubserver/pluginconfig/com.priint.pubserver.preferences.InDesignServerInstances/custom/InDesignServerInstances.xml config file in the configs repository (using ISON Eclipse [Repository view]). This file should look like this: 

<?xml version="1.0" encoding="UTF-8"?><con:PluginConfig xmlns:con="com.priint.pubserver.config.manager/20130620">
    <con:name>InDesignServerInstances.xml</con:name>
    <con:type>InDesignServerInstances</con:type>
    <con:description>InDesignServerInstances.xml</con:description>
    <con:custom>
        <cfg:InDesignServerInstances xmlns:cfg="http://priint.com/pubserver.appserver.config/v1">
            <cfg:InDesignServerInstance instanceID="001" serverID="4">
                <cfg:instanceName>PDF Renderer 1</cfg:instanceName>
                <cfg:endpoint>local://C:\\pdf_renderer\\</cfg:endpoint>
                <cfg:active>1</cfg:active>
                <cfg:typeID>1</cfg:typeID>
            </cfg:InDesignServerInstance>
            <cfg:InDesignServerInstance instanceID="002" serverID="4">
                <cfg:instanceName>PDF Renderer 2</cfg:instanceName>
                <cfg:endpoint>local://C:\\pdf_renderer\\</cfg:endpoint>
                <cfg:active>1</cfg:active>
                <cfg:typeID>2</cfg:typeID>
            </cfg:InDesignServerInstance>
        </cfg:InDesignServerInstances>
    </con:custom>
    <con:dependencies/>
    <con:instances/>
</con:PluginConfig>

You can add or remove instances by directly editing the XML file. Please note the restrictions for element and attribute values listed below:

INSTANCEID must be unique

SERVERID must be the ID of the PDFRENDERER entry in the InDesignServers.xml configuration file.

INSTANCENAME must be unique (see path information above)

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

Settings for each instance are

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

instance configuration

priint:renderer Instance Type or Purpose

To seperate long running tasks like generating pages from tasks, which require fast response times, priint: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 priint:renderers

Connecting to remote priint:renderers requires an additional server component. This is a very tiny WebService component delivered as an EJB ear file called CometPdfRemote.ear. The CometPdfRemote component can be installed on Windows and Mac.

Installation

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

Installation instructions

Note: if you update a previous (pre 4.1 Build 1580) version of the CometPdfRemote component, please undeploy the old CometPdfRemote.jar application first, shutdown Glassfish and remove the following libraries from your domain lib directory:

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.

Note: when editing Windows path, you should be aware of a bug in the Glassfish administration console: Backslashes must be escaped (e.g. C:\\comet_pdf\\) but will appear unescaped in the input fields after committing changes. When submitting the form for several times, each value must be revised, even if the value has not changed.

The following two properties are optional:

properties

Paths and Folders

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

Cache Path

This path is used by the priint: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 an absolute 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: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 an absolute 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: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 an absolute 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: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:renderer Instances

Under priint:suite > Administration > InDesign instances you find a list of configured InDesignServer instances and information about the current status, whether it is 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 priint:publishing server / priint:renderer running on the same or on dedicated hosts.
Please note:

priint:publishing server and priint: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.

priint:publishing server and priint:renderer on dedicated Windows Machines

priint:publishing server on Windows, priint: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