HTML/Email report formatting problems

Version Relevance: V1.00 onwards

Issue: Some reports do not translate well to HTML format, and hence cannot be used for emailing (V3 has PDF attachments to email and only oprionally HTML). How can I improve the formatting on these reports?

Feb 16th, 2006

Feedback: HTML (without CSS) is a crude formatting standard that doesn't come close to matching the native report generator. When an Omnis Studio report is rendered to HTML, it must convert all the elements into tables, and it is this process that can cause problems, with additional tables being created unexpectedly. Also, any report elements or code relating to multiple page behaviour are no longer appropriate (an HTML report is a single page of variable length), and this can also cause problems.

To achieve consistent rendering in HTML, it is best to create a custom version of the report for just this purpose. The following list of tips, while by no means exhaustive, seems to address most of the issues.

HTML report modifications

  1. Avoid "optional" fields (fields that may by empty) in record section (HTML rendering sometimes creates a new table for an "empty" object, rather than in including it in the current table for that line).

    Create new method $printrecord, with method lines something like: -
    If POLISSU=''
      Calculate POLISSU as 'n/a'
    End If
    If POLSPTN=''
      Calculate POLSPTN as 'n/a'
    End If
    Do default


    This is not always necessary, but be prepared.
  2. Ensure field widths are sufficient for full length of data, and that there is sufficient space between fields that HTML rendering can identify them as separate table cells.
  3. Use custom page size of zero length, and remove footer section from report class. Remove any testspace parameters from positioning sections and record section.
  4. Insert a normal iControlHeading (no calculation, with nosection/lineifempty set etc.) in section containing record column titles, and insert new otherwise empty section underneath to contain iControlHeading and iPrintLine "switch-off" objects (just put them next to each other on a single line). This prevents the column headings trying to print more than once (which breaks up HTML table).
  5. Ensure there is a normal iControlHeading in first sections, to prevent them trying to print more than once.
  6. Remove page numbering elements.
  7. For reports that use the the TaxList Data Grid, replace the column header literals with separate text boxes just above, and turn off the Data Grid property "Show Header"; this prevents a separate HTML table being printed for each column header.
  8. Avoid adjacent fields with different field styles, and/or different heights, for example a text field with a carriage return in it next to one without. Also try to avoid mixing floating and non-floating fields in the same line.
  9. If you only have one text field in a section, then even if it is empty it will create a large table in the report. leading to lots of white space. Make sure you set "nolineifempty" for these.

Paul Wilson - Caliach Consultant