Case Print

This chapter describes the operation writeTextualCase and common principles of how to print a case and adapt the desired output. For the REST-API please refer to COMPASS Service API documentation: printApplication. The description of the adaption of the XSL-T stylesheet is valid for both the operation writeTextualCase and printApplication.

The writeTextualCase operation requires a case as input and creates a textual result. Thus the writeTextualCase needs a caseSourceReference and a textDestinationReference that specify where COMPASS finds the Input Interface and where it should place the textual result. Please refer to API Overview for more details about requests, operations, caseSourceReference and textDestinationReference.

The DTD of the writeTextualCase operation can be found in the file ./config/dtd/request.dtd and is as follows:

The XML representation of the operation writeTextualCase for ScreenBuilder 1 protocol is wrapped in the XML element reportPrintSection. This reportPrintSection contains 1 or more casePrintSections. Every casePrintSection has a header-text that is stored in the attribute heading. Its attribute id contains a string “n_mmm“ where n is a number that denotes the type of the CaseObject (e.g. 27 for Assured Persons), and mmm stands for the textual representation of the id-attribute of the object. A further attribute tells us whether a POS-Module for this CaseObject has been cancelled. The value of the attribute cancelled is true, if and only if there was a POS-Module which was cancelled by the user. Additionally every casePrintSection can contain other casePrintSections or screens. A screen is a structure that describes a screen. screens and their sub elements like groups or questions are described in detail in the document Screenbuilder 1.0 protocol.
Thus we have the following DTD:

A casePrintSection groups all information from the application for a certain context. This context can be an AP (assured person), a disorder, a pursuit, etc. Technically we can say that every CaseObject of the Input Interface is represented by a casePrintSection, as long as there is displayable information about the CaseObject.

casePrintSections that wrap another casePrintSection stand for a certain relation between the two related CaseObjects. E.g. a casePrintSection for the AP “James Bond” can contain another casePrintSection for a disorder “diabetes”; what tells us that James Bond suffers from diabetes. In this case the sub-casePrintSection for diabetes contains all the details about the diabetes, e.g. start date, hospitalisation (yes/no), etc.

Every casePrintSection has a heading (as described by the DTD), which specifies a “title” for the section, and contains the name of the related CaseObject. It makes sense to display this heading-text, so that the following information can be related to the CaseObject.

The sequence of screens and casePrintSections within a casePrintSection corresponds to the sequence of screens as defined in the SourceType. It makes sense to display the screens in the order as given by the XML representation, as this reflects the order in which they appeared during the data recording/answering of the application form.

Let us explain using the following example of an XML representation:

In the application form, as defined in the SourceType, the details for “Golf” and “Boxing” have been asked directly after the screen “Pursuit Selection James Bond”. Thus the casePrintSections for these CaseObjects (Golf and Boxing) have been included right after this screen.

The customer is nevertheless free to rearrange the screens in their visualisation, if another order is preferred.

Screens with some of their elements (buttonRow, message and navigation elements do not appear in this context) should be displayed as explained in the ScreenBuilder documentation.

One exception is their id-attribute. This attribute contains basically the value underscore “_”.

The XML representation of the operation writeTextualCase or the Service endpoint printApplication based on the ScreenBuilder 2 protocol are very similar to a screen built for capturing via ScreenBuilder 2. Its DTD is in fact identical and is described by the file config/dtd/screenSB2.dtd.

The XML - structure of a screen is explained in the document Screenbuilder 2.0 protocol. At this point we will only focus on the differences between a SB2 capture-screen and a SB2 application-print screen.

The main difference is the attribute current for an item. During capturing, exactly one item receives the attribute current with its content = "true", while all other items have their current - attribute set to "false". In the application-print screen, all items have their current - attribute set to "true". I.e. all items contain their full set of questions and answers.

There are many attributes of the XML-elements that are most likely unnecessary for the application print. Nevertheless, they have been kept maintaining an identical structure between both XML screens. A list of (probably unnecessary) attributes follows:

For the item element:

For the person element:

For the question element:

For the relation element:

For the textInput element:

For the text element:

For the value element:

For the relationElement element:

For the numberInput element:

For the unit element:

For the selection element:

For the dateInput element:

Starting from the XML representation of the application, COMPASS will create an HTML representation of the application data, if the operation writeTextualCase or the endpoint printApplication are configured accordingly. For the transformation from XML to HTML COMPASS uses the XSL-T technology and requires several style-sheets, that can be modified by the customer to achieve a different appearance of the generated HTML-output.

A basic understanding of the previous chapter and the definition of a screen (see Screenbuilder 2.0 protocol or Screenbuilder 1.0 protocol) is required for this chapter. Some basics are explained below:

A simple screen like

is represented by the XML - element screen (only some sections shown):

Every screen consists of a group, which again can consist of several other groups. Groups can contain texts, answer fields, selection boxes and other graphical widgets. All of these elements have a position, appearances, layouts, etc.

During the transformation from a screen to the HTML output all these attributes (height, position, fillStrategy, etc) have to be considered. The result will look like:

When using COMPASS to generate the HTML output, you might redefine the SourceType with the RulemanagerApp to create a more “printable” output. This includes the selection of other widgets (radio buttons vs. selection boxes, other colours, changing the screen order, etc). It is convenient to not modify the existing SourceType, but to create a copy of the SourceType for your modifications.

Additional modifications on the appearance of the HTML result can be achieved via adapting the XSL Style Sheets.

Five XSL-style sheets are required by COMPASS to generate HTML based on the XML output of the operation writeTextualCase or the Service endpoint printApplciation. These five files can be found in the script-directory of your COMPASS installation, and are explained in detail in the following:

Starting from the XML representation of the application, COMPASS will create a PDF representation of the application data, if the operation writeTextualCase / the Service endpoint printApplication are configured accordingly.

The transformation to PDF uses the Apache FOP processor. The XSL files are therefore XSL-FO layout descriptions. Currently the FOP version 2.1 is required.

To create such a XSL-FO file, a basic understanding of the definition of a screen (see Screenbuilder 1.0 protocol or Screenbuilder 2.0 protocol) is required. Chapter HTML-Output does include a description of a screen.

When using COMPASS to generate the PDF output, you might redefine the SourceType with the RulemanagerApp to create a more “printable” output. This includes the selection of other widgets (radio buttons vs. selection boxes, other colours, changing the screen order, etc). It is convenient to not modify the existing SourceType, but to create a copy of the SourceType for your modifications.

Additional modifications on the appearance of the PDF can be achieved by adapting the XSL Style Sheet described in the next lines:

To transform a ScreenBuilder 1 XML - document into PDF, the file script/pdfConverter.xsl is used.

An application according to the ScreenBuilder 2 - protocol is transformed into PDF with the file script/pdfConverter2.xsl.

It is possible to further modify the XSLT-files with any appropriate tool/editor.

When COMPASS is shipped, sample XSL-files script/pdfConverter.xsl and script/pdfConverter2.xsl are included in the delivery. COMPASS needs this file to be placed in the script - directory. The generated output of the operation writeTextualCase / the Service endpoint printApplication is located in the ./casedata directory.

We will not go into detail here about this XSL-file, but it is worth mentioning that the sample XSL-files include references to some images that are also part of the delivery which can be found in the script/images directory.

The shipped transformation makes use of some third party jars, which are
commons-io-1.3.1.jar
commons-logging-1.2.jar
xmlgraphics-commons-2.1.jar
batik-anim-1.14.jar
batik-constants-1.14.jar
batik-i18n-1.14.jar
batik-parser-1.14.jar
batik-shared-resources-1.14.jar
batik-util-1.14.jar
batik-xml-1.14.jar
fop-2.7.jar
fop-core-2.7.jar
fop-events-2.7.jar
fop-util-2.7.jar
xmlgraphics-commons-2.7.jar

When COMPASS is shipped, certain fonts are required to produce the suggested PDF look and feel. These fonts are typically part of the Windows operating system, so you will not notice in case they are not included in the deployment.

This might be different, particularly when COMPASS runs on an operating system such as Linux. In this case, those fonts have to be downloaded somewhere and made available. This can be done by placing them in the default operating system fonts directory or into the COMPASS directory ./script/fonts.

The following fonts are required, and are not shipped due to license reasons:

arial.ttf
arialbd.ttf
arialbi.ttf
ariali.ttf
times.ttf
timesbd.ttf
timesbi.ttf