One of the most powerful features of UniPhi is the Rich Text Box element in a UniPhi Document Template. Documents in UniPhi are then available to generate a PDF version for emailing or printing for distribution to clients and team members.

Within that Rich Text Box you can create tables for presentation of information as a part of the document preparation. While this is similar to the many word processing applications, it is actually based in the language of the web, HTML.

This need not be an issue for the user and for most it is a transparent process. However, sometimes as we try to format tables we actually provide too many conflicting instructions to the table and while the HTML on-screen view may appear ok, the PDF version can struggle to address the conflicting information.

An example of this is particularly when trying to present multiple tables with consistent width’s.

As with any HTML formatting the overall table width is driven by the width of the content in the table cells. The width of a table and cells can be left as ‘undeclared’ or ‘blank’ and the table will default to a width that accommodates the widest item in any one cell in any column. e.g. if you have a 6 x 6 cell grid and in each of the rows you place a 100px wide item (like an image) in each column (regardless of which row) then the overall width of the table will be forced to 600px (6 x 100px) and even if you declare that the table should be fixed to only 400px the fact that the images are already too wide will automatically expand the table width to accommodate the content.

Using the merge cells option is another area that tends to be over-used and can create consistency issues between multiple tables. Again it comes down to width and content.

So how does this play out in UniPhi?

The recommended process is to never declare the table width until you know the total width of the columns and preferably declare a fixed width for each cell in the top row or header row of the table. That way any modifications to widths can be edited in just one place.

Assigning the cell widths should be done from left to right on the top row only. Do not assign widths to column or row selections. Issues can arise if the columns are assigned a width and then an adjustment is made to an individual cell, such that if the cell widths previously declared are still active in the rows elsewhere in the table may over-ride the desired settings in the top row.

Merge cells should be avoided if at all possible. While we acknowledge that they can be useful this tends to be only when a table is presented in isolation. For presentation purposes two separate tables with slightly different merged cell combinations will generally present inconsistently in width assuming that the content of the table cells is also inconsistent (which it invariably is. Why would you be presenting the identical information twice ?)

So the rules for merged cells are:

1) avoid them specifically if you have more than one table in the same document and the audience is important and you do not want inconsistency,

2) if you must have a merged cell format when more than one table will be presented, then make sure the tables have identical merged cell layouts to minimise the likelihood of inconsistency.

3) if you do have multiple tables with different layouts and different content, then perhaps it is easier to leave them as having different overall widths, get the document sent and move on to the next document. Sometimes the effort of being pedantic is not beneficial for either your productivity or your sanity!

For the HTML guru’s and web-masters cringing at the thought of tables!

The use of tables is considered by many to be ‘old-school’ and against the principles of later standards of HTML. However that needs to be weighed against the purpose of the UniPhi system. It is not a web presentation system where css styles and different audiences will have different browsers and devices to contend with.

The UniPhi document creation & management system provides for the generation of standardised documents within a Project Management framework for the purpose of generating PDF snapshots of project status and project processes that can universally be accessed either on-screen or printed formats. In order to achieve that outcome the use of tables is still practical and preferred.