From version 4 onwards InDesign® Comet plug-ins support data connections with the priint PublishingServer. Some formerly project-specific requirements have become standard.
Good News: Apart from few exceptions, Comet 4 and the PublishingServer work just like before. More good news: Some things are far easier to realize.

• the PublishingServer enables access to user data via a project-specific entity model; thus, the development of placeholders, templates, the logic of building, layout, make-up etc. is entirely independent from the actual data source, which significantly simplifies working with mockups at the beginning of the implementation as well as porting existing Comet configurations for new data sources at the end of a project cycle.
• data are almost exclusively processed on the server, project-specific requirements can be realized as a Java plug-in on the server.
  The script language cscript, which is integrated into Comet plug-ins, is now only needed for exceptions and the control of working processes.
• in cases where cscript is unavoidable in placeholders or tables, new cscript functions make data access easier and data accesses configured in the PublishingServer can be directly employed.
  Attention! Requests through functions of the query module are possible with a PublishingServer connection, but no longer supported by the Professional Service. Also, the underlying protocol may change in new versions or function patches without prior notice.
  Therefore, please contact the Professional Service (support@priint.com) if the use of query functions seems inevitable - surely we will find an alternative!
• placeholders, scripts and configurations specific to InDesign® panels are administrated via priint:ison.
  Due to this, editing scripts in InDesign® is not possible anymore.
• a solution available through a simple cscript function request is provided to create tables of contents.
• the handling of product and article IDs has been standardized.
  The StringID contains all information needed to determine hierarchy and context; a number of new tags as well as cscript functions enables the request and use of single components of this ID.
• filing and integration of cscript libraries have been standardized through priint:ison and a new cscript 'include' command.
• the following functions are not necessary any longer and therefore no longer supported :
  • grid-oriented building (grid panel and the respective configuration data). Use page templates instead.
  • framerules. Fitting functions can be realized through template behavior and page templates.
    

In the PublishingServer environment, the StringID contains all relevant information to determine hierarchy and context. As a rule, the numeric IDs ID, ID2 and ID3 have therefore become obsolete (for reasons of validity, ID must not have the value 0, which is why it is always set to 1).

The StringID is structured in the following way (but without the only for better readability inserted line separators):

 recordId
#groupId
#entityId
#entityClass
#parentRecordId
#parentGroupId
#parentEntityId
#parentEntityClass

In placeholder scripts, single components of the StringID can be accessed via the following tags, environment variables and/or cScript functions:

In TableInsert methods, the following tags and/or environment variables are defined:

Moreover, two new tags are supported in all environments:

• <xml.identifier>: Access to XML attributes of the root element of the document. These attributes can be set manually in InDesign® or by means of the module xml, e. g. xml::set_document_attribute. identifier designates the name of the attribute.
  In the PublishingServer environment, these tags are mostly employed to embed context variables, publication IDs etc. into the document. In scripts, the values of these attributes can be determined via xml::get_document_attribute.
• <layer.1..3>: Part of the layer name. The layer name can consist of up to 3 segments separated by hash signs ("#"), enabling targeted access to each segment. Again, context criteria in the PublishingServer environment are the main field of application.

In order to modularize cscripts or reuse own cscript functions, script libraries can be created in priint:ison. Further information can be found in the priint:ison user manual.
A identifier is attached to these libraries, making it possible to integrate them into cscript:

 #include "[pubserver]/Identifier.h" 

Methods of your (server) Java plug-ins can be used via commands according to the following scheme:

#include "[pubserver]/plugin/Plugin-mapped-name.c"

Documented headers of functions available for a Java Plugin can be obtained with this include instruction (caution, this is for documentation only, this code cannot be interpreted by the cscript interpreter):

#include "[pubserver]/plugin/Plugin-mapped-name.h"

Methods of all available Plug-Ins can be obtained this way:

#include "[pubserver]/plugins.c"

Or, again, just the documented headers of all Plug-Ins:

#include "[pubserver]/plugins.h"

Finally the include directive for the CScriptStandardLibrary:

#include "[pubserver]/stdlib.c"
// Shortcut for:
#include "[pubserver]/plugin/com.priint.pubserver.comet.bridge.cscript.CScriptStandardLibrary.c" 

And the documented function signatures:

#include "[pubserver]/stdlib.h"
// Shortcut for:
#include "[pubserver]/plugin/com.priint.pubserver.comet.bridge.cscript.CScriptStandardLibrary.h"

For more information see section Calling up own Java plug-ins.

Several new cscript functions make sense especially in the PublishingServer environment and have been documented thoroughly in the respective module:

• idtype::record_id(char * stringId)
• idtype::group_id(char * stringId)
• idtype::entity_id(char * stringId)
• idtype::entity_class(char * stringId)
• idtype::parent_record_id(char * stringId)
• idtype::parent_group_id(char * stringId)
• idtype::parent_entity_id(char * stringId)
• idtype::parent_entity_class(char * stringId)

In the PublishingServer environment, placeholders are configured exclusively via priint:ison. Data access takes place via DataProviders (also configured in priint:ison).
For detailed information, see the PublishingServer documentation; here only a short introduction:
A DataProvider fulfills two tasks:

• definition of the data access, usually via calling up a method of the EntityManager
• display of the data in a structure adequate for the output system (here: InDesign® or the pdf renderer)

As a result, implementing further data preparation through cscript should not be necessary (before such a decision, see Layout rules).
If it seems unavoidable nevertheless, the standard load method of the placeholder can be called up through the cscript function

server::load_placeholder_str 

For detailed documentation and examples, click here.

Example: Loading a placeholder
This script has no effect at all; it just loads the text via the access method that is configured on the server, including all conversions and adaptations, and finally inserts the text into the placeholder - which is the same one would expect without script.
In order to give it a certain meaning anyway, we write the text that we got from the server into the log file before:

int main ()
{
	String		str 		= string::alloc();
	int			result 		= server::load_placeholder_str(str);

	wtlog("", "load_placeholder_str result=%d, text='%s'\n", result, str);

	if (result == 0)
	{
		textmodel::replace(str);
	}

	string::release(str);
	return result;
}

Example 2: Overwriting parameters
Key value pairs can be set as third ... nth parameter. The names of PublishingServer-specific tags are useful keys, e. g. Record.Id, Entity.Id, Entity.ContextLanguage etc.
This makes it possible to "bend" placeholders and, for instance, specify a context (to be determined client-sidedly). Whether this makes sense and it would be better to configure an adequate context rule for the placeholder, is another story...

int main ()
{
	String 		str 	= string::alloc ();
	int			result 	= server::load_placeholder_str(
							str,
							"Entity.ContextLanguage", "eng",
							"Model.Id", "Anderes_Datenmodell");

	wtlog("", "load_placeholder_str result=%d, text='%s'\n", result, str);

	if (result == 0)
	{
		textmodel::replace(str);
	}

	string::release(str);
	return result;
}

These information apply to classical table building; besides, server-side building of tables is possible in the PublishingServer. Which option works best varies from case to case.
During client-side (classical) generation, it is deposited for columns, rows and single cells which method product or article IDs for the building of the table are determined with. These are the so-called TableInsert methods that can be set up via priint:ison, too.
The principle is similar to that of placeholders: Data are loaded via a DataProvider that additionally deals with the transformation into an adequate structure - there are two differences, however:

• the output type of the DataProvider (i. e. the DataMapping method deposited for this DataProvider) has to be com.priint.pubserver.comet.entitydata.RecordId. For further information, see the documentation of the CometBridge or the CometBridgeSDK.
• TableInsert methods define no additional methods for data preparation. Since we only determine IDs, this would not make any sense.

In the seldom case that the IDs have to be determined in a separate cscript, you can access the standard load function of the TableInsert method like this:

server::load_table_ids(gProducts, gMoreGroups) 

For detailed documentation and examples see here.

Example: The simplest TableInsert script
This script behaves "neutral", meaning that the result would be the same if one directly executed the method configured for the column, row or cell:

int main ()
{
	return server::load_table_ids(gProducts, gMoreGroups);
}

Just like with the server::load_placeholder function, values can be overwritten through key value pairs as third .. nth parameter.

Similar to placeholders or tables, you can load (almost) arbitrary DataProviders in an arbitrary script environment. In this case, you have to enter all necessary values (normally adopted automatically from the placeholder or table context) manually (as key value pairs of the function "pass on as").
Please note:

• you define the result type of the DataProviders with the variable "pass on as resultBuffer". At the moment, the following data types can be processed:
  • char *: As result, a single string (the first one delivered by the DataProvider) is returned
  • StringList: The result is returned as a simple string list
  • IDTypeList: As result, a list of idtype IDs is delivered
  • ProductList: As result, a list of products is delivered
  There is a server- as well as client-side effort to convert the data appropriately. The result is not necessarily reasonable; it is therefore important to know the DataProvider used and to restrict oneself to the following combinations
  
  • char *: only for DataProviders with result type String or List<String>
  • StringList: only for DataProviders with result type String or List<String>
  • IDTypeList: only for DataProviders with result type List<RecordID>
  • ProductList: only for DataProviders with result type List<Product>
• a fitting alloc function must allocate the list passed on as a parameter (or the char *) in the script, otherwise the result type cannot be recognized.
• the list also has to be released in the script itself. If you intend to use the values externally, they possibly have to be copied into a global list defined through the context.

For detailed documentation and examples see here.

 href="../../cscript/server.html#dataprovider_load">server::dataprovider_load() 

Example: Filling an IDTypeList

int main ()
{
	IDTypeList 	ids 	= idtypelist::alloc();
	int 		result 	= 0;
	int 		index  	= 0;
	
	result = server::dataprovider_load(ids, "ChildBuckets", 0, 0, "Record.Id", "<Record.Id>");
	if (result == 0)
	{
		// copy ids to the global IDTypeList gProducts (will only work this way, if executed as a TableInsert method)
		for (index = 0; index < linklist::length(ids); ++index)
		{
			idtypelist::insert(gProducts, -1, idtypelist::get(ids, index);
		}
	}
	// clear list, but do not clear entries
	idtypelist::clear(ids, 0);
	return result;
 }

Example: Getting a simple string

int main ()
{
	char 	* 	value 	= alloc(32768); 
	int 		result 	= 0;
	
	result = server::dataprovider_load(value, "FirstText", 0, 0, "Record.Id", "<Record.Id>", "Entity.ContextLanguage", "deu");
	if (result == 0) 
	{
		textmodel::replace(value);
	}
	release(value);
	return result;
}

This requires the installation of the Java server plug-in CometTableOfContents.
The plug-in provides special DataQuery methods which, in connection with an accordingly configured DataProvider and a text placeholder of the entity Table Of Contents, enable access to table-of-contents data in your InDesign® or PDF document. For configuration of the data access see the documentation of the priint-ison application.

Table-of-contents entries can be created by calling up the cscript function

linklist::insert_toc_entry()

Example: Creating table-of-contents entries of a a certain placeholder 

#include "internal/types.h"

int main ()
{
	LinkList 	placeholders = linklist::alloc(1);
	int 		result;
	
	linklist::insert(placeholders, 67301234);
	result = linklist::insert_toc_entry(placeholders, kDesignateDocument, "myPublication", "12345"); 
	linklist::release(placeholders);
	
	return result;
}

Java methods of a PubServer Plugin can be invoked in cscript. Some prerequisites must be fulfilled:

• the Java method must be annotated as @PubServerMethod
• in addition, the method must be annotated as @CometCScriptFunction
• all parameters of this method must be annotated as @PubServerMethodParameter
• regarding supported types for parameters and return values there are some limitation, see section Type-Mapping

Example 1 - Hello

The basic concept is best explained with this example (we expect basic knowledge in Java and cscript programming):

@Stateless(mappedName=HelloWorld.MAPPED_NAME)
@LocalBean
@PubServerPlugin
public class HelloWorld extends PluginControlDefault {
	
	public static final String MAPPED_NAME = "com.priint.pubserver.comet.cscript.HelloWorld";
	
	/**
	 * Hello World
	 * 
	 * @return Hello World
	 */
	@PubServerMethod(type=PluginMethod.MethodType.GENERIC)
	@CometCScriptFunction
	public String helloWorld() {
		return "Hello World";
	}
}   

#include "[pubserver]/plugin/com.priint.pubserver.comet.cscript.HelloWorld.c"
     
int main()
{
    char 	* 	message = helloWorld();
    
    showmessage("Server said: %s", message);
    release(message);
    
    return 0;
}

Example 2 - Parameters

The second example shows, how to pass parameters to a method:

@Stateless(mappedName=HelloWorld.MAPPED_NAME)
@LocalBean
@PubServerPlugin
public class HelloWorld extends PluginControlDefault {
	
	public static final String MAPPED_NAME = "com.priint.pubserver.comet.cscript.HelloWorld";
	/**
	 * Hello World
	 * 
	 * @return Hello World
	 */
	@PubServerMethod(type=PluginMethod.MethodType.GENERIC)
	@CometCScriptFunction
	public String helloWorld2(@PubServerMethodParameter String login) {
		return "Hello " + login + "!";
	}
}   

#include "[pubserver]/plugin/com.priint.pubserver.comet.cscript.HelloWorld.c"

int main()
{
    char 	* 	login   	= alloc(4096);
    char 	* 	message 	= 0;
    
    login   = system::login(login);
    message = helloWorld2(login);
    showmessage("Server said: %s", message);
    
    release(message);
    release(login);
    
    return 0;
}

Résumé:

• Java methods of a PubServer Plugin annotated as @PubServerMethod and @CometCScriptFunction can be invoked as a cscript function using the method name as function name
• to do so, the Java Plugin must be included in the cscript using a special include-directive
• schema for this directive is
     #include "[pubserver]/plugin/<Mapped Name of the Plugins>.c"

• Java data types are mapped to cscript data types according to certain rules (in the examples we mapp String to char* and vice versa)

• the signature (i.e. name, number and type of arguments) of the cscript function is exactly the same as the signature of the Java method (beside of type mapping)
• (implied, but quite important): in cscript I do not have to bother about memory allocation, but results of a Java method call must be released (unless for the simple types int and float or if null is returned).

More basic information

• the cscript code for PubServer Plugin methods annotated as @CometCScriptFunction is generated at runtime.

• this means: the method, the generated code and headers are available only as long as the Java Plugin is deployed on the server

• this also means: changes in Java methods take effect immediately - without having to restart the publishing server or having to logout / login with InDesign® (probably the script cache must be cleared)

• cscript function names are derived from the Java method names. Any valid cscript identifier is allowed (fortunately this corresponds with Java naming conventions), except for keywords (int, return, if ...) and names of builtin-functions of the cscript language (such as "strcmp" oder "alloc").
  
  If for any reason your Java method must be named alloc, you can specify a different name for the cscript function using the name attribute of the @CometSCriptFunction annotation:

  @PubServerMethod(type=PluginMethod.MethodType.GENERIC) 
  @CometCScriptFunction(name="alloc_")
  public int alloc(... 

• parameter names are not derived from Java parameter names, but are built up by a prefix and consecutive numbers (__gcsarg1_ .. __gcsargn_). To specify a parameter name, you can use the name attribute of the @PubServerMethodParameter annotation.

  @PubServerMethod(type=PluginMethod.MethodType.GENERIC) 
  @CometCScriptFunction
  public int min(
  	@PubServerMethodParameter(name="value1") int n1,
  	@PubServerMethodParameter(name="value2") int n2) ...
  

  needless to say, that the following will lead to errors:

  @PubServerMethod(type=PluginMethod.MethodType.GENERIC) 
  @CometCScriptFunction
  public int min(
  	@PubServerMethodParameter(name="value") int n1,
  	@PubServerMethodParameter(name="value") int n2) ...
  

  Parameter names should not start with the prefix __gcs, because we use this prefix for local variables. The following example will cause errors also, though it's not so obvious:

  @PubServerMethod(type=PluginMethod.MethodType.GENERIC) 
  @CometCScriptFunction
  public int min(
  	@PubServerMethodParameter int n1,
  	@PubServerMethodParameter(name="__gcsarg1_") int n2) ...
  

The cscript language and Java language - though similar regarding the syntax - differ in many aspects:

• in cscript supports functions only; subroutines always return a value, often errors are indicated by a special error value (e.g. nonzero).
• Java-methods can be functions (with) or procedure calls (without return value); errors are indicated by Exceptions

The @CometCScriptFunction allows to specify, whether the cscript stub for a Java method uses should be called as a function or as a proceddure, no matter, if the method returns a value or not. Use the attribute callStyle:

• CallStyle.FUNCTION: the cscript functions returns the value returned by the Java method
• CallStyle.PROCEDURE: return value of the cscript function is (int)0 or the ErrorCode of the exception raised by the method.

Example 1 - "function"

@Stateless(mappedName=HelloWorld.MAPPED_NAME)
@LocalBean
@PubServerPlugin
public class HelloWorld extends PluginControlDefault {

	@PubServerMethod(type=PluginMethod.MethodType.GENERIC)
	@CometCScriptFunction(callStyle=CallStyle.FUNCTION /* = default! */ )
	public int max(
			@PubServerMethodParameter(name="n1") int n1, 
			@PubServerMethodParameter(name="n2") int n2) {
		return n1 > n2 ? n1 : n2;
	}
}   

// function signatur<
int max(int n1, int n2);

// example call
int n = max(17, 23);

Example 2 - "procedure"

@Stateless(mappedName=HelloWorld.MAPPED_NAME)
@LocalBean
@PubServerPlugin
public class HelloWorld extends PluginControlDefault {

	@PubServerMethod(type=PluginMethod.MethodType.GENERIC)
	@CometCScriptFunction(callStyle=CallStyle.PROCEDURE)
	public void sendEmail(
			@PubServerMethodParameter(name="recipient") String recipient) throws CometException {
		try {
		 	deliverEmail(recipient);
		}
		catch (Exception e) {
			int errorCode = 13;
			throw new CometException(errorCode, "Could not deliver Email, reason: " + e.getMessage(), e);
		}
	}
}   

// function signature
int sendEmail(char* recipient);

// example call
int errorCode = sendEmail("support@priint.com");

Example 3 - "procedure with return value"

@Stateless(mappedName=HelloWorld.MAPPED_NAME)
@LocalBean
@PubServerPlugin
public class HelloWorld extends PluginControlDefault {

	@PubServerMethod(type=PluginMethod.MethodType.GENERIC)
	@CometCScriptFunction(callStyle=CallStyle.PROCEDURE)
	public String sendEmail(
			@PubServerMethodParameter(name="recipient") String recipient) throws CometException {
		try {
		 	deliverEmail(recipient);
			String status = getMailDeliveryStatus();
			return status;
		}
		catch (Exception e) {
			int errorCode = 13;
			throw new CometException(errorCode, "Could not deliver Email, reason: " + e.getMessage(), e);
		}
	}
}   

// function signature
// An additional parameter is inserted at the front of the  
// function parameter list (char** out), see explanations
// above.
int sendEmail(char** out, char* recipient);

// example call
char* status = 0;

// please note the address-operator, we pass the address of
// the string (char*) pointer. If call succeeds, status points
// to a valid char* address, otherwise status will remain null.
int errorCode = sendEmail(&status, "support@priint.com");

if (errorCode == 0) {
	wlog("", "Sending mail succeeded, current status: %s\n", status);
}
else {
	wlog("", "Sending mail failed with error code '%d'\n", errorCode);
}
if (status != 0) {
	release(status);
}

Example 4 - error handling using function style

Unless specified otherwise, the return value of a function on errors is

• pointer types (i.e. all but int and float) null
• for int (int)0, for float (float)0.0

If another value should be returned in case of errors, you can use the failureValue attribute of the @CometCScriptFunction annotation.

Note:

• the failureValue attribute is supported for char*, int and float return type
• the failure value defined for a method is also returned by the cscript function, if calling the method fails at all (e.g. network errors, session expired etc.)

@Stateless(mappedName=HelloWorld.MAPPED_NAME)
@LocalBean
@PubServerPlugin
public class HelloWorld extends PluginControlDefault {
	
	public static final String MAPPED_NAME = "com.priint.pubserver.comet.cscript.HelloWorld";
	/**
	 * Hello World
	 * 
	 * @return Hello World
	 */
	@PubServerMethod(type=PluginMethod.MethodType.GENERIC)
	@CometCScriptFunction(failureValue="You are not welcome. Goodbye.")
	public String helloWorld3(@PubServerMethodParameter String login) throws PubServerException {
		if (login.equals("me")) {
		    return "Hello " + login + "!";
		} 
		else {
			throw new AuthenticationFailureException();
		}
	}
}   

#include "[pubserver]/plugin/com.priint.pubserver.comet.cscript.HelloWorld.c"

int main()
{
    char 	* 	login   	= alloc(4096);
    char 	* 	message 	= 0;
    int 		result   	= 0;
    
    login   	= system::login(login);
    message 	= helloWorld3(login);

    // in real life you chould check for null
    if (strcmp(message, "You are not welcome. Goodbye.") == 0) 
    {
		showmessage("Hello world failed: %s", message);
		result = 1;
    }
    
    release(message);
    release(login);
    
    return result;
}

The Java / cscript interface supports the types listed below as parameter or return types.

General directives in cscript:

• variables passed as parameters - except for the primitive types int and float - must be allocated before.
• the return value of a function - again except for the primitive types int and float - must be released, unless 0 was returned.
• string literals can be passed for char* parameters, but the address of a string literal must never be used for the out variable of a procedure style method call.

// valid:
WorkflowStatus 	status = 0;
status = getStatusOfPublication("67110123");
publication::workflowstatus::release(status);

// invalid:
WorkflowStatus status = publication::workflowstatus::alloc();
status = getStatusOfPublication("67110123");
publication::workflowstatus::release(status);
// Why? The memory formerly allocated for status is not 
//      referenced any more and therefore can no more be released.

// valid, but dubious:
WorkflowStatus status = publication::workflowstatus::alloc();
publication::workflowstatus::release(status);
status = getStatusOfPublication("67110123");
publication::workflowstatus::release(status);

// valid, but dubious:
char * publicationId = "67110123";
publicationId = findParentPublication(publicationId);
release(publicationId);

// wrong!
int n = getMax(17, 23);
release(n);

The @PubServerMethod, @CometCScriptFunction and @PubServerMethodParameter annotations allow detailed documentation of the Java methods and corresponding cscript functions.
At the time (Version 4.0.5) there is no support for this in the Ison editor, so cscript developers must derive all information from the Java classes and methods - or download generated headers with documentation using a suitable tool.

You can use the Placeholder Options panel in InDesogn Desktop (this requires a developer license for the comet Plugins):

Enter a File ID in the Script ID / File ID field and click the disk symbol to download this file.

Start with File-ID [pubserver]/plugins.c, this will list all available includes, Example::

#include "[pubserver]/plugin/com.priint.pubserver.comet.cscript.HelloWorld.c"
#include "[pubserver]/plugin/com.priint.pubserver.comet.cscript.PrimitiveTypes.c"
#include "[pubserver]/plugin/com.priint.pubserver.comet.bridge.cscript.CScriptStandardLibrary.c" 

Now you can repeat this procedure for any include of interest.

Alternatively you can download [pubserver]/plugins.h , this will show all function signatures including inline documentation:

/**
 * <p>sophisticated hello world example</p>
 * <p>
 *   This is a more sophisticated hello world example.
 *   
 *   The PubServerMethod label and description are used for cscript inline
 *   documentation.
 *   Try downloading
 *     [pubserver]/plugin/com.priint.pubserver.comet.cscript.HelloWorld.h
 *   from your client application (e.g. InDesign® Desktop), to see the effect.
 *   The following cscript code calls this method:
 *   <pre>
 *     #include "[pubserver]/plugin/com.priint.pubserver.comet.cscript.HelloWorld.c"
 *     int main() {
 *       char * login = alloc(4096);
 *       char * hello = helloWorld3(system::login(login));
 *       showmessage("Server said: %s", hello);
 *       release(hello);
 *       release(login);
 *       return 0;
 *     }
 *   </pre>
 * </p>
 * @return char*
 * @param char* login user login on the client host
 */
char* helloWorld(char* login);
...

Question

Can I define only one cscript / Java method per Plugin?

Answer

Of course not, you can define an arbitrary number of methods. The more methods, the larger the generated cscript stub code will be, therefore you should not define too much methods in one Plugin.
There is a second reason, why too many methods in one Plugin could cause problems: function names must be unique in cscript. It is not possible to overload functions in cscript.

The resulting limitations apply for methods in one Plugin and also for methods in all Plugins, that potentially are included in one cscript at the same time: if Plugin A contains a function named foo and Plugin B contains a function named foo also, they cannot be included in one cscript at the same time.

Question

Can I propagate existing Java methods as cscript functions?

Answer

Yes, if your method is part of a PubServerPlugin and if you respect the limitations regarding supported types mentioned above. In this case, all you have to do is add the @CometCScriptFunction annotation to your method..

Question

What about performance?

Answer

When invoking Java methods from cscript, the following happens: cscript objects and values are serialized to XML, the XML is sent to the PubServer via SOAP, the server unpacks the SOAP message and parameter XML and invokes the Java Plugin. The call result is again transformed in XML, sent back to InDesign® via SOAP, unpacked, unserialized and assigned to the cscript result variables. Sounds like much effort and costs.

Typically a roundtrip (without any calculatino done on the server) should take about 30ms. This is an acceptable overhead for complex operations, but far too much for simple calculations (such as strcmp, strcat ...), which can easily and much more efficient be implemented in cscript.

Question

Why is the char resp. Character type not supported?

Answer

There is no suitable corresponding XML Schema builtin type for single characters. But more important: single characters could be misinterpreted, because strings in cscript are utf-8 encoded. This means, a visible character can consist of several character bytes. All cscript string functions respect this: the length returned by strlen is the number of visible characters, not of character bytes; any string position in any function refers to visible characters (not bytes).

Question

What is the maximum length for Strings returned from Java methods?

Answer

Virtually infinite. The memory is allocated dynamically.

Question

Is the number and size of parameters limited?

Answer

No - at least not regarding translations and transport.

Questions

Are tags (such as <Record.Id> ...) supported in scripts, which include Java methods?

Answer

Java methods can be included in any cscript: placeholder scripte, panel scripts, layout rules, build scripts etc.
Which tags and global variables are available, depends on the call environment, there are no exceptions for scripts including Java methods.

Question

Can I access document poperties from Java?

Answer

Only those passed as parameter. The communication is unidirectional, you cannot callback InDesign® from the Java Plugin. Therefore it's neither possible to access document frame properties nor to manipulate page items from your Java Plugin.

Question

We were talking about InDesign®, is the cscript / Java bridge supported in the PDF Renderer too?

Answer

yes, of course.