Expected Workflows

One of the main ideas behind Layout Editor is that it should provide a more simple, lower cost alternative to Layout Developer for those users who need to create or finish documents manually. There are two main workflow types associated with this kind of work which are supported:

• Document Production — how Layout Editor will be used to create or finish documents and generate output

These two types are considered here as an indication of how to include Layout Editor into your production workflows. As is normal for Layout Developer, we do not prescribe a particular workflow, so please use this information as guidance.

There are two types of template to consider:

• Automated templates — where most or all of the document production work is carried out automatically based on template code, whether that is on a server (using Publishing Engine) or on a users desktop computer

• Manual templates — where the template provides all the necessary formatting styles and page layouts, but the user chooses how they’re going to be applied

When a template is to be used on a server, it should be deployed as a normal ALD template (.3f). If the expectation is that manual work will be required in Layout Editor, there are some things to consider:

• If the content is to be edited, ensure that the main content stream is an XML stream (.xm tag) rather than an XML DOM (.xd tag). XML DOM tags are not easy to edit.

• Ensure that the file saved is a Layout Editor file using the tsavele macro or fTemplate.saveLE() FOM method.

If the automated template is to be deployed and used in Layout Editor, there should be no difference in behaviour between Layout Developer and Layout Editor as far as the scripting processes are concerned. The .3lf template file type should be used. Layout Editor users can run scripts and perform the same tasks as in Layout Developer, within the restrictions described elsewhere in this document. Note that these restrictions include editing and changing scripts, styles and control streams. See the Appendix for more information.

When deploying manual templates to Layout Editor, they will be provided as Layout Editor files — either .3le or .3lf files. This means that testing the document file extension in the ‘autoexec’ script will not work in the same way. The user will likely benefit from helper tools for some tasks, which can easily be deployed as either a library or as part of the template.

Be aware of the following when developing template scripts:

• Layout Editor users will not be able to edit template code tag types as text — if a control stream needs to be changed, provide a tool to do this.

• Users will be able to create, load and edit text and graphic content but it would be helpful to provide tools to do this work

• The debugger is not available to Layout Editor users. It is not possible to open a socket connection in Layout Editor.

When developing templates for Layout Editor, it can be useful to know whether the template is attempting to perform restricted operations. A command-line parameter has been provided, —alewarning, which will tell Layout Developer to generate warnings for restricted operations. The warnings generated are written to the standard error log locations including the Application message window in the debugger.

Layout Editor is intended for manual document work. Opening a Layout Editor file will perform the same tasks as opening a Layout Developer file in Layout Developer. The user is given access to page layouts and content. Layout Editor users can create new content types (text, XML and graphics) and can and edit those items. The Layout Editor user can also create new frames on the Main Page layer and add content to them. The other layers within the document are locked.

Creating output is unchanged in Layout Editor, the user has access to all the same print capabilities. SPRINT control streams should already be part of the template, if those are in use. Properties within SPRINT control streams can also be driven by variables, so if changes are required to these, template developers should provide tools to do this.

Layout Editor restricts a lot of developer-type functionality, but one place that allows a lot more of this behaviour is when libraries are loaded. During the library load process many of the restrictions are lifted, including access to strings below 4000 and executing certain macros. Libraries should be used for distributing customisations to Layout Editor users.