From the Print Attributes section of the report, you can choose to output the report in PDF, Word, Excel, HTML, or XML format, as shown in Figure 9-10.

Figure 9.10. Available output formats

So rather than outputting in PDF format, the user might want to output the report in a format that can be easily used in Microsoft Word, for example. However, if we change the Output Format setting to Word, then it is set to output in Word for every user. We want the application to be a bit smarter (and more user-friendly) than that, and let the user specify the output format.

To allow users to select the output format, we add a new select list to the report, which lists each of the different output formats and the value we need to pass across to the print server (BI Publisher in this example) to produce the output in that particular format. We can create a static LOV for the select list, as shown in Figure 9-11.

Figure 9.11. LOV for output formats

Notice the valid values for the return values in Figure 9-11 (PDF, RTF, XLS, HTML, and XML). Make sure you use these values; otherwise, you will not get the output in the desired format. Of course, you don't need to provide all of the output formats to the end users. You could just provide PDF and Word for example, or perhaps provide different formats to different users depending on their privileges.

We now need to change the Output Format setting to use the Derive From Item option, rather than one of the hard-coded options, and we specify the select list as the item from which to derive the output format. In this example, the select list is named P1_OUTPUT_FORMAT, as shown in Figure 9-12.

Figure 9.12. Allowing dynamic output format

We have also modified the File Name attribute in Figure 9-12 to be BUGS. This is actually the same name as the region itself (which would be used as a default), but we want to make sure the output is always called BUGS, even if we rename the region.

You can also modify the settings for the page attributes of the output, such as the paper size, orientation (landscape or portrait), borders, and so on. For our Buglist report, it makes sense to print the output in landscape format because we expect the rows to be wide.

Another interesting feature is the ability to define a page header and page footer for the output, as shown in Figure 9-13.

Figure 9.13. Specifying a page header for the output

A very nice feature of the Page Header and Page Footer options is that you can reference session state. For example, in Figure 9-13, we have used the value of the APP_USER session state to show the name of the user who produced the report. This could be very useful for auditing purposes. You could extend this simple example to reference a session state item that contains the current date and time, so that it is clear from the output when the report was produced (so that you can see whether the data is current).

You can also define which columns should be included in the output. Why would you want to do this? Well, consider the case where you might want to display some sensitive information (such as customer bank account details) on the screen, but you don't want that information to be printed and taken off-site. Figure 9-14 shows the Report Columns section, where you can choose whether to include or exclude individual columns in the output. In this example, we have excluded the ID column from the output.

Figure 9.14. Including and excluding columns in the output

Notice that you can also change the width of each column in the output. The width is expressed as a percentage of the overall width. You can either specify the values for the widths yourself or use the Recalculate button to calculate the new values based on what you have entered.

We have changed a number of settings in the report. Let's see the results. Figures 9-15 and 9-16 show the output in PDF and HTML format.

Figure 9.15. PDF output including header and custom column width

Figure 9.16. HTML output including header and custom column width

Notice how the HTML version isn't exactly the same as the PDF output. For example, the header isn't centered, and the width of the DESCRIPTION column doesn't seem to have honored the width percentage we specified. However, as a first attempt at producing the output in multiple formats, it's still impressive.

We begin to create our new report layout by first creating a new query. Go to Shared Components page, which has two options in the Reports section:

In this example, we want to create a report query based on the same query used in the Buglist report, so that we can get an XML representation of the data that is going to be sent to the print server. We need to use a query that gives us the same layout of data and includes the columns we want to use in the report layout. We also want to take into account whether the user has filtered the report in any way, since we want the printed report to reflect the same data that the on-screen report is displaying. So, we can create a new report query and use the same session state item.

Choose Report Queries to start the Create Report Query wizard, as shown in Figure 9-18 (depending on your version of APEX, the Create Report Query wizard may look slightly different). In Figure 9-18, we are basing the output format on an item (P1_OUTPUT), and we have included the P1_REPORT_SEARCH item session state. You can include as many session state items as you need here.

The next step in the wizard asks us to specify the query that is going to be used to generate the data. Listing 9-3 shows the query for the Buglist report (changed slightly to make it more readable—notice the ellipses in the subqueries).

Figure 9.18. Creating a new report query

SELECT

  bl.id,
  bl.bugid,
  bl.reported,
  bl.status,
  bl.priority,
  bl.description,
  bl.reported_by,
  bl.assigned_to,
  bl.cost,
  (select ur.email from user_repository ur
     where ur.username = bl.reported_by)
    as reported_email,
  (select initcap(ur2.forename) || ' ' || initcap(ur2.surname) from
     user_repository ur2 where ur2.username = bl.reported_by)
    as reported_full_name
FROM buglist bl
WHERE
(
 instr(upper(bl.status),upper(nvl(:P1_REPORT_SEARCH,bl.status))) > 0 or
 instr(upper(bl.priority),upper(nvl(:P1_REPORT_SEARCH,bl.priority))) > 0 or
 instr(upper(bl.description),upper(nvl(:P1_REPORT_SEARCH,bl.description))) > 0 or
 instr(upper(bl.reported_by),upper(nvl(:P1_REPORT_SEARCH,bl.reported_by))) > 0
)

Notice that we are using the value of the P1_REPORT_SEARCH page item in the query in the predicate.

The next screen in the wizard is shown in Figure 9-19. You can see that currently the report query contains a single query. You can add extra queries by clicking the Add Query button. This gives you the flexibility of creating a report that contains data from two unrelated queries.

Figure 9.19. Source query definition

At this point, you can choose to create the report query. However, for this example, before we do that, we need to download the XML data from the query, because we are going to use that XML output to design our custom report layout.

You can choose to download the XML either as plain XML data or as an XML schema. The difference between the two choices is that the XML data file, as the name implies, contains the real data that is generated from running the query, while the XML schema file creates an XML document that details the definition of the XML document itself, without the data. The XML data will typically be much larger than the XML schema; however, the XML data has the benefit of allowing us to test the report layout in BI Publisher Desktop, since we'll have some data to display, so we'll choose this option for the example.

Listing 9-4 shows the format of the XML data file, and Listing 9-5 shows the format of the XML schema file. We have not reproduced the files in full, since they are quite large, but it can be helpful to see the content of these files to get an idea of how they differ.

<?xml version="1.0" encoding="UTF-8"?>
<DOCUMENT>
    <DATE>12/24/2010</DATE>
    <USER_NAME>TGF</USER_NAME>
    <APP_ID>101</APP_ID>
    <APP_NAME>Oracle APEX AppBuilder</APP_NAME>
    <TITLE>Bugs</TITLE>
    <P1_REPORT_SEARCH></P1_REPORT_SEARCH>
    <REGION ID="0">
        <ROWSET>
            <ROW>
                <ID>1</ID>

<BUGID>1</BUGID>
                <REPORTED>01/27/2006</REPORTED>
                <STATUS>Open</STATUS>
                <PRIORITY>High</PRIORITY>
... rest of content omitted

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="DOCUMENT">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="DATE"/>
        <xs:element ref="USER_NAME"/>
        <xs:element ref="APP_ID"/>
        <xs:element ref="APP_NAME"/>
        <xs:element ref="TITLE"/>
        <xs:element ref="P1_REPORT_SEARCH"/>
        <xs:element ref="REGION"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="DATE">
    <xs:simpleType>
      <xs:restriction base="xs:string"/>
    </xs:simpleType>
  </xs:element>
  <xs:element name="USER_NAME">
    <xs:simpleType>
      <xs:restriction base="xs:string"/>
    </xs:simpleType>
  </xs:element>
... rest of content omitted

Also notice in Listing 9-4 that the P1_REPORT_SEARCH session state item appears in the XML. This is why we needed to include this item when creating the report query. If we didn't, it would not be included in the data. (It could still be referenced from within the query inside APEX; it just would not be available in the report.)

After we download the XML data, we fire up Microsoft Word (which has the BI Publisher Desktop plug-in installed). We can now load the XML data into BI Publisher Desktop, as shown in Figure 9-20. After doing so, we'll get a message stating that the data has been loaded successfully.

Figure 9.20. Loading the XML data

Now the fun begins, as we begin designing the report layout. We can use basic Word functionality and create a page header to give the report a heading of "Bug Report." We could also include the current date and time if required, but we'll keep this layout simple.

We want to include each row in the XML data (that is, each bug) in the report. The BI Publisher Desktop tool contains some nice wizards that walk you through choosing the fields and data you want to include. We recommend using the wizards as much as possible to generate the code automatically. You can view that code to see how it works. Then, if desired, you can create fields manually or make adjustments if the wizards don't do precisely what you want.

For this example, we'll use the Table Wizard, as shown in Figure 9-21, and select the Free Form format.

Figure 9.21. Creating a free-form report format

Next, we need to choose the grouping field, which refers to the repeating field in the data. The wizard gives us the following two choices (based on the data we loaded):

If you look back at the format of the XML data in Listing 9-4, you will see that each row is represented by the DOCUMENT/REGION/ROWSET/ROW element, so we select that as the grouping field.

Next, we need to select the fields that will be included in the report, as shown in Figure 9-22. And in the next step of the wizard, we can choose a field to sort the data by. In this case, it makes sense to sort the data by descending reported date.

Figure 9.22. Selecting the fields to display in the report

Figure 9-23 shows the output of the wizard. You can see that all it does is insert form fields that represent the fields from the XML document. The Word document also includes a form field named F at the beginning and a form field named E at the end. These two form fields are there to allow the fields to be repeated for each record.

Figure 9.23. The Word document includes form fields

Since we imported the XML data file into BI Publisher Desktop, we can now test the report from within the tool itself, without having to export the report layout into APEX. This is a quick way to prototype a report layout. We can even choose to preview the output in several different formats: PDF, HTML, Excel, and RTF (future versions of BI Publisher might support other formats).

Figure 9-24 shows the preview in PDF format. Admittedly, the layout isn't exactly pretty just yet, but it shows how easily we can control the positioning of the fields, as we now have a vertical style layout. Notice that the records run together with no spaces in between. As a quick exercise, go back to the Word document containing the template and add a blank line immediately before the "end ROW" field. When you preview the report again, you'll see that the records are separated by a blank line.

We could now make this report look a bit nicer by using standard Microsoft Word functionality. Figure 9-25 shows a new Word document containing a modified report layout. We created a table and positioned the XML elements for the columns (the form fields essentially) inside the table cells. We also assigned a contrasting table-shading color scheme to distinguish the definition of each individual bug.

If you previewed the report again, you would see a much more visually appealing report. However, let's continue and add a few other nice features before we finish with this report.

Figure 9.24. Previewing the report layout

Figure 9.25. Creating a nicer layout for the report

Let's also include a line in the report that displays the search criteria that was used to generate the report. In the printed report, this will show whether the records were filtered. We can easily do this by adding an extra line at the top of the page that reads as follows:

Search Criteria: P1_REPORT_SEARCH

This would certainly meet the requirements; however, the line would be included in the report whether or not we actually provided a filter. So, if we simply ran the report and displayed all the records, we would have a line that read "Search Criteria:" at the top of the page. It would be nice to be able to suppress that line unless P1_REPORT_SEARCH actually contains a value, wouldn't it? Well, as you've guessed, we can do that!

To control whether the "Search Criteria" line is displayed, highlight it and choose the Insert Conditional Region menu option. This will allow us to specify a condition that is evaluated to determine whether to show that region, as shown in Figure 9-26.

Figure 9.26. Adding a conditional region to the report

Essentially, the condition states that the entire "Search Criteria" line should be displayed only if the P1_REPORT_SEARCH field is not empty. As shown in Figure 9-26, the result of using the conditional region is that a new form field named C (for Condition) is placed before the "Search Criteria" text, with a closing form field of EC (for End Condition) placed after the P1_REPORT_SEARCH form field.

Once you become comfortable with how the form fields work, you can begin to create them manually. We can examine the code behind the conditional region we just added by highlighting the entire line and choosing Tools Field Browser. This brings up a window that displays the form fields and the code behind each one, as in this example:

C                 <?if:P1_REPORT_SEARCH!=''?>

P1_REPORT_SEARCH  <?P1_REPORT_SEARCH?>
EC                <?end if?>

So, to create a conditional region, you could type the code that is behind the C form field, and use whatever logic you like in the condition. To display a particular XML element, for example, you could type the code <?ELEMENT?>.

Another nice addition to the report would be to highlight any bugs that have a high priority. We can do this by using conditional formatting (as opposed to a conditional region). We select the PRIORITY form field and then choose Insert Conditional Format. This displays the Properties dialog box shown in Figure 9-27, which allows us to specify two conditions to allow the field to be formatted differently depending on the conditions.

Figure 9.27. Adding conditional formatting to the report

If two conditions are not sufficient, you can use the Advanced tab to manually enter the code. Examining the code for this condition, we see the following (formatted here to make it easier to read; in the editor, it will most likely appear as one long line):

<?if:PRIORITY='High'?>

  <?attribute@incontext:color;'red'?>
<?end if?>
<?if:PRIORITY!='High'?>
  <?attribute@incontext:color;'green'?>
<?end if?>

Let's preview the report in BI Publisher Desktop. The results are as shown in Figure 9-28.

Figure 9.28. Previewing the new report

Along with the priority being displayed in a different color depending on the condition we specified (which may not be apparent in the figure), notice that the line that specifies the search criteria is not present. This is because the XML data file that we loaded does not contain a value for the P1_REPORT_SEARCH session state item, as shown here (and in Listing 9-4):

<?xml version="1.0" encoding="UTF-8"?>

<DOCUMENT>
    <DATE>09-JUL-08</DATE>
    <USER_NAME>ADMIN</USER_NAME>
    <APP_ID>103</APP_ID>
    <APP_NAME>APEX - Application Builder</APP_NAME>
    <TITLE>Bugs</TITLE>
    <P1_REPORT_SEARCH></P1_REPORT_SEARCH>
    <REGION ID="0">
        <ROWSET>
... rest of listing omitted

However, when a user runs the real report through APEX, any value that is typed into the P1_REPORT_SEARCH field will be passed through in the XML data to BI Publisher, and then the conditional region should display.

So now that we have created the report layout, how do we use it in APEX? With BI Publisher, all we need to do is to save the Word document that we created as an RTF file. Note that no other format will work (so be careful not to accept the default Save As type of Word document). Once you have saved the layout as an RTF file, you can upload it into APEX to be used as a report layout.

If you recall, we left APEX back at the Create Report Query wizard (Figure 9-19). Now we return to APEX and go to the next page in the wizard, where we can choose to upload the new RTF, as shown in Figure 9-29.

Figure 9.29. Uploading the RTF report layout

Notice that for the Report Layout Source option, we have selected "Create file based report layout." The default option is "Use generic report layout," which is the original tabular layout.

Once we've uploaded the RTF layout, we get the option to test the report (which you should do). We also are provided with a URL that can be used from a link or button within the application to generate the report. In this case, the URL is as follows:

f?p=&APP_ID.:0:&SESSION_ID.:PRINT_REPORT=Bugs

Notice how the value for the REQUEST parameter in the URL uses the name of the report as a parameter to the PRINT_REPORT command.

We can now go back to the original Buglist report in the Buglist application and change the Report Layout setting from Default Report Layout to our new Bug layout. You will see all your custom report layouts in the drop-down list in the Print Attributes section.

Now run the application and type something into the search field to filter the records displayed in the report. Then click the Print Bugs link. The PDF version will display the same records as the on-screen report. Figure 9-30 shows an example of the report produced when we entered "error" in the search field. You can see that because we supplied a value for the P1_REPORT_SEARCH page item, the "Search Criteria" line is included in the report.

Figure 9.30. Filtered PDF output

This quick example has illustrated just how easily you can create very advanced and dynamic reports using BI Publisher. However, before we finish this section on using BI Publisher, let's add a couple of other nice features just to show how powerful BI Publisher is.

As we mentioned earlier, the layout code is actually an XSL document. It is broken into the following sections:

In the main code section, we see code like the following:

<fo:table-header>

  <fo:table-row>
    #PRN_TEMPLATE_HEADER_ROW#
  </fo:table-row>
</fo:table-header>
<fo:table-body>
  <xsl:for-each select=".//ROW">
    <fo:table-row>
      #PRN_TEMPLATE_BODY_ROW#
    </fo:table-row>
  </xsl:for-each>
</fo:table-body>

This section is responsible for outputting the headers and detail for the records (in other words, this small section is responsible for the vast majority of what we see in the outputted PDF). Much of the rest of the main code is responsible for how the page is formatted and laid out (as opposed to displaying the actual data). Listing 9-6 shows some of that formatting and layout information.

<xsl:attribute-set name="header-font">

  <xsl:attribute name="height">
    #HEADER_FONT_SIZE#pt
  </xsl:attribute>
  <xsl:attribute name="font-family">
    #HEADER_FONT_FAMILY#
  </xsl:attribute>
  <xsl:attribute name="white-space-collapse">

false
  </xsl:attribute>
  <xsl:attribute name="font-size">
          #HEADER_FONT_SIZE#pt
  </xsl:attribute>
  <xsl:attribute name="font-weight">
          #HEADER_FONT_WEIGHT#
  </xsl:attribute>
</xsl:attribute-set>

Even if you're not familiar with XSL-FO (or with XSL), it should be reasonably obvious that the section of code in Listing 9-6 is responsible for the font settings for the header. Notice the references to things that look like APEX substitution strings, such as #HEADER_FONT_SIZE#. These values are actually passed across as the values you set in the Report Attributes section for your report.

Now let's take a look at the section responsible for the column headings, shown in Listing 9-7.

<fo:table-cell xsl:use-attribute-sets="cell header-color border">

  <fo:block xsl:use-attribute-sets="text #TEXT_ALIGN#">
    <fo:inline xsl:use-attribute-sets="header-font">
            #COLUMN_HEADING#
          </fo:inline>
  </fo:block>
</fo:table-cell>

The code in Listing 9-7 is remarkably short. This brevity really is one of the powers of XSL: a short code fragment can be used multiple times for many different data elements. This block of code is actually called as a result of the #PRN_TEMPLATE_HEADER_ROW# substitution variable we saw in the main block of code, or more precisely, this section of code is embedded into the main block of code as it is represented by the #PRN_TEMPLATE_HEADER_ROW# variable.

Let's try something relatively simple. We'll change the report headings so they're in italic and also use a red font. The way that we change the font for the heading is to add a font-style attribute to the column heading section of the XSL-FO (Listing 9-7). For example, the following column heading section uses font-style to ask for red, italic font:

<fo:table-cell xsl:use-attribute-sets="cell header-color border">

  <fo:block xsl:use-attribute-sets="text #TEXT_ALIGN#">
    <fo:inline xsl:use-attribute-sets="header-font"
      font-style="italic" color="red">
            #COLUMN_HEADING#
          </fo:inline>
  </fo:block>
</fo:table-cell>

We added font-style="italic" color="red" to the fo:inline section of the code. You might notice that this is very similar to what you would do in HTML to modify the text.

If you ran the application again, after assigning the new layout to the report, you would see that the headers are indeed in italics and use a red font. However, adding a font style in this way is really not the "correct" way to change font attributes, as we are not using pure XSL-FO.

Notice that in the fo:inline section, we state that for any following text, we want to use the values from the header-font declaration:

<fo:table-cell xsl:use-attribute-sets="cell header-color border">

  <fo:block xsl:use-attribute-sets="text #TEXT_ALIGN#">
    <fo:inline xsl:use-attribute-sets="header-font"
      font-style="italic" color="red">
            #COLUMN_HEADING#
          </fo:inline>
  </fo:block>
</fo:table-cell>

What we should really do is include our new formatting (italic and red) in the definition for the header-font section, which you saw in Listing 9-5. We can now modify that section of code, as shown in Listing 9-8.

<xsl:attribute-set name="header-font">

   <xsl:attribute name="height">
     #HEADER_FONT_SIZE#pt
   </xsl:attribute>
   <xsl:attribute name="font-family">
     #HEADER_FONT_FAMILY#
   </xsl:attribute>
   <xsl:attribute name="white-space-collapse">
          false
   </xsl:attribute>
   <xsl:attribute name="font-size">
          #HEADER_FONT_SIZE#pt
   </xsl:attribute>
   <xsl:attribute name="font-weight">
          #HEADER_FONT_WEIGHT#
   </xsl:attribute>
   <xsl:attribute name="font-style">
           italic
   </xsl:attribute>
   <xsl:attribute name="color">
           red
   </xsl:attribute>
</xsl:attribute-set>

Now if we run the report, we should again see the header font is in italics and the color of the header is red, as shown in Figure 9-38.

Figure 9.38. PDF showing XSL-FO changes

Notice that the headings are not nicely lined up, due to some of the headers being wider than the columns are defined to be. We could modify the heading alignment and column widths, although we could also specify those items through the Report Columns section in the Report Attributes, as described earlier in the chapter. In fact, we could have also very easily changed the header color through the Report Column Headings section in the Report Attributes. However, we could not specify that the header should be in italics using that method. Italics need to be set manually in the XSL-FO code.

As another example, let's say we want to highlight bugs that are a high priority. Looking at the code for the column template, we see the following:

<fo:table-cell xsl:use-attribute-sets="cell border">

    <fo:block xsl:use-attribute-sets="text #TEXT_ALIGN#">
        <fo:inline xsl:use-attribute-sets="body-font">
            <xsl:value-of select=".//#COLUMN_HEADER_NAME#"/>
        </fo:inline>
    </fo:block>
</fo:table-cell>

We have two choices here: we can explicitly check that we're processing the PRIORITY column and then check to see if the value is 'High', or we can just check to see if the value is 'High' (regardless of which column it is in). Since we are using the generic column layout rather than using named columns, it is much trickier to check specifically for the PRIORITY column. So, we'll go with the approach of displaying any column value that matches 'High' in red.

The xsl:choose syntax essentially allows us to perform an if-then-else operation in XSL.

<xsl:choose>

  <xsl:when ...>
          ...
  </xsl:when>
  <xsl:otherwise>
          ...
  </xsl:otherwise>
</xsl:choose>

We will use this syntax to check if the value of the current column is 'High' (and display it in red); otherwise, we display it normally. Replace the contents of the Column Template with the following code:

<xsl:choose>
  <xsl:when test=".//#COLUMN_HEADER_NAME#='High'">
    <fo:table-cell xsl:use-attribute-sets="cell border">
      <fo:block xsl:use-attribute-sets="text #TEXT_ALIGN#">
        <fo:inline xsl:use-attribute-sets="body-font-red" font-style="italic">
          <xsl:value-of select=".//#COLUMN_HEADER_NAME#"/>
        </fo:inline>
      </fo:block>
    </fo:table-cell>
  </xsl:when>
  <xsl:otherwise>
    <fo:table-cell xsl:use-attribute-sets="cell border">
      <fo:block xsl:use-attribute-sets="text #TEXT_ALIGN#">
        <fo:inline xsl:use-attribute-sets="body-font">
          <xsl:value-of select=".//#COLUMN_HEADER_NAME#"/>
        </fo:inline>
      </fo:block>
    </fo:table-cell>
  </xsl:otherwise>
</xsl:choose>

We use the xsl:choose construct to check the value of the current column in the data. The first case is when the column value does equal 'High'. Notice the parts we have highlighted. The first is where we test (using the test keyword) the current value of the column and compare it to a string. We have used the same notation for referring to the column value that was used in the original code.

.//#COLUMN_HEADER_NAME#

This allows us to reference the current XML element in the XML document that contains the data from the report.

Also notice that we changed the fo:inline statement to use the body-font-red attribute set, rather than the original body-font. This is because we need to display the value differently in both cases. So we need to add another attribute set to the main code. To do this, we simply copied the body-font attribute-set and added a color attribute to make the font appear in red.

:

<xsl:attribute-set name="body-font">

  <xsl:attribute name="height">
    12.0pt
  </xsl:attribute>
  <xsl:attribute name="font-family">
    #BODY_FONT_FAMILY#
  </xsl:attribute>
  <xsl:attribute name="white-space-collapse">
    false
  </xsl:attribute>
  <xsl:attribute name="font-size">
    #BODY_FONT_SIZE#pt
  </xsl:attribute>
  <xsl:attribute name="font-weight">

#BODY_FONT_WEIGHT#
  </xsl:attribute>
</xsl:attribute-set>
<xsl:attribute-set name="body-font-red">
  <xsl:attribute name="height">
    12.0pt
  </xsl:attribute>
  <xsl:attribute name="font-family">
  #BODY_FONT_FAMILY#
  </xsl:attribute>
  <xsl:attribute name="white-space-collapse">
    false
  </xsl:attribute>
  <xsl:attribute name="font-size">
    #BODY_FONT_SIZE#pt
  </xsl:attribute>
  <xsl:attribute name="font-weight">
    #BODY_FONT_WEIGHT#
  </xsl:attribute>
  <xsl:attribute name="color">
    red
  </xsl:attribute>
.....................

So to summarize, the column template will check the value of the current column. If it is equal to the string 'High', it will use the new body-font-red attribute-set; otherwise (if it is not equal to 'High'), it will use the original body-font attribute-set.

If we now run the report, we should see that any bugs with a priority of High have the PR-IORITY column marked in red (we've also used italics to make it more noticeable in the figure), as shown in Figure 9-39.

Figure 9.39. Highlighting High priority in red and italics