The M040 maintenance release of APP Version 11 was recently made public. This release provides the usual bug fixes and also some new functionality which will be of interest to APP users and Styler users (as APP is the default print composition engine).
The key things are:
This is provided as a technology preview. Here, you get the ability to create PDFs with annotations (sticky notes) which can be populated with content extracted from your XML (inlcuding comments if you're smart). When you create the PDF note, you get to specify the title, the author, the content, the colour of the note and the icon used. Currently the icon is one of seven which are predeifined, but I'd be interested to hear if you want more. What I like about this feature is that it allows you to add information to a PDF, such as asking a reviewer a question or including deleted content, without changing the formatting of the page by adding extra content inline.
This is another technology preview which gives users the ability to create a PDF layer and tell APP to include the contents of a frame on that layer. There is a new FOM object (fPDFlayer) which holds properties such as the "visible state" and the "print state" of the layer as well as other meta-information about its role. What you can do with PDF layers is pretty powerful. One use I've seen is to include different language content in the same area on a page, but allow the reader to turn off and on the languages they want.
Block and table names
One of the challenges of hand-crafting templates in APP can be to make sure you end the right blocks or tables when they're nested. To help with this we've added a name property to blocks and tables which can then be used when closing those formatting objects. If you have a mismatch, you can generate an error or warning which will allow you to identify where the problem is.
Block and table hierarchy information
Along with adding names to blocks and tables, we have also exposed hierarchy information about nested blocks and tables. There are two parts to this. We now have the idea current block and table objects which provide information about the current block (as well as the current block region and row) and the current table (as well as the current table row and cell). The information you get is presented as a 'resolved' object, meaning that APP has figured out how it needs to format that object and presents real values through the resolved version of the object.
There is also block and table hierarchy information. This lets you look up through the nested structures you're in to figure out what the properties of those structures are. For example, if you know you're in a three-column block but you don't know where that column configuration is set, you can navigate back up the hierarchy to find it. You can then use that information to make sure that your column spans are not causing APP difficulty or you know how many blocks to close to be able to sensibly reset the column configuration.
Running header names
In APP you used to have 10 groups of running headers. This means you could have up to 10 simultaneous pieces of information being stored during formatting for use in headers or footers. The additions of named running headers means you can have up to 10 groups of simultaneous information being stored. This means way more information can be stored, giving greater flexibility to what you display in headers and footers. For example, you can assign one group to hold all titles and name each item in the title group according to the level of title you're storing. Styler source has been updated to use this system.
When you format a document with indexes, ToCs and cross references in, those chunks of generated content take up space. It is impossible to know how much space they'll take up before you format, so often you need to format a document several times before these things settle down to their final values. But how do you know it has settled? This feature helps that decision by allowing you to say "I know this content stream of XPath expression is likely to change, so I'll keep an eye on it". When the watched things don't change, a template property tells you that the formatting pass was stable, so you can print. This effectively takes away at least one un-necessary formatting pass of the document, which is great for performance.
APP has a couple of ways to override system files, but they're pretty heavy. There is now a new system file – scustom_paths.3ad – which you can use to specify alternative load paths for any of the system files. You can specify up to 10 alternative locations for APP to check for any of the files which would be located within APP's install folder or any of the subfolders. Part of the reason for doing this is Windows being unfriendly when poking around with program files, but it also makes it easier to add customisations for customer solutions.
To help you get to grips with these features, I've attached a ZIP file to this entry which contains some documentation and some sample files. Let me know how you get on!