The document and opendoc (open document) parameter types allow the Client Composer to package an XML document for transmission to the Arbortext PE server. The parameter type codes document and opendoc may be specified alone or followed by suffixes requesting certain kinds of optional processing. For example, a parameter with a type of opendoc.location would be considered an opendoc parameter with a suffix requesting location processing (described in the Optional Parameter Suffixes table).

For a parameter of type document, the parameter value must be the absolute path to an XML or SGML document. The Arbortext Publishing Engine Client Composer will ask Arbortext Editor to open the document, process the document as if it was an opendoc document, and then close it again. The document will be opened using the following flags:

The Client Composer calls Arbortext Editor and directs it to open a document by calling the Java method Application.openDocument(path, flags). It species the absolute path to the document for path and sets a flags parameter to flags corresponding to the conditions described in the previous list.

For a parameter of type opendoc, the parameter value must be the ACL ID of a document that is already open in Arbortext Editor. The document is left open, and no changes are made to it.

For both document and opendoc parameter types, the Client Composer will copy the document in memory, modify the copy by processing it, and then write the document using a temporary name to the input directory. The name will begin with the string x followed by a number needed to make the name unique. The name will end with the file extension .xml, .html, or .sgml.

The Client Composer will adjust the parameter’s value to the name of the file in the input directory, and the parameter's type will be adjusted to entry.

If the Client Composer is given a document parameter named testfile with a value of c:\test\inputfile.xml, the Arbortext Publishing Engine Server Composer will receive an entry parameter named testfile with a value of something like x10.xml. The x10.xml file in the input directory would be the modified version of the file c:\test\inputfile.xml on the client.

The Client Composer always begins processing a document or opendoc parameter by cloning the document in question, making a temporary copy in memory, and replacing entity references with the actual data (sometimes referred to as a flattened document). Flattening entity references ensures that the document will have no references to other XML or SGML documents when it is written to disk, which is important because the referenced documents might not be accessible to the Arbortext PE server.

After the document has been opened, copied, and flattened, subsequent processing is controlled by any suffixes included on the document or opendoc type code, as described in the following table.

Graphics are copied unless .gl are specified.

To convert ISO graphics, only one of .iso-eps, .iso-jpg, or .iso-png may be specified. If none of these are present, then ISO graphics are not converted.

If the .location suffix is present on the type code, the Client Composer optionally inserts location processing instructions. The PIs allow a DVI file returned by the Arbortext PE server to reference locations in the ACL document, which would occur when publishing PDF, PostScript (print composed), and preview. The .location suffix supports the Edit > Synchronize Editor Position feature in Arbortext EditorPreview window.

Next, the Client Composer processes graphics referenced by the flattened document by copying all of the graphics referenced by the document to a subdirectory of the input directory. After graphic handling is processes, the Client Composer will write the flattened document to the input directory for transmission to the Arbortext PE server.