CDR Tickets

BZDATETIME::2011-03-01 18:29:42
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

I believe there are two problems here:
a) The table has 5 columns but it has been created as though the first column
is spanning two columns.
I believe this has been done in order to make the first column wider than
the right 4 columns. Otherwise the "section header" rows would wrap.
b) From what I can find on the Internet there exists an IE bug that hits when
a colspan is being used.
Another example like this can be seen here:
http://nutritionwebservices.com/WebDev/IE8-Broke-Tables-With-ColSpan-Width.htm
The document displays nicely in Firefox and Chrome but not in IE.

The combination of (a) and (b) is causing the current table display. Without the "extra" column the column width for each column would be identical but with the extra column the width of the first column becomes extra large.

Without the ability to specify the column width in the CDR in absolute terms I don't think this is something we're able to fix.

BZDATETIME::2011-03-03 19:15:56
BZCOMMENTOR::Robin Juthe
BZCOMMENT::2

Volker and I talked about this a bit after the CDR meeting today and we would like to discuss a couple issues related to tables in an upcoming status meeting:

-establishing column widths in the CDR (not currently feasible in absolute terms - ie using percentages)
-allowing lists within tables (Victoria's request)

The second topic isn't directly related to this issue, but it might make sense to make these changes together, if we decide to make them.

BZDATETIME::2011-04-01 11:14:07
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::3

Bob and Volker are going to investigate this further. I believe Bob will be investigating/researching IE bugs or fixes for this and Volker will be researching what needs to be done on the cancer.gov side. There was also talk of specifically addressing the broader problem of Xmetal table issues. (Not sure I got this right :-))

BZDATETIME::2011-05-12 08:36:56
BZCOMMENTOR::Bob Kline
BZCOMMENT::4

(In reply to comment #3)

> Bob and Volker are going to investigate this further.

The basic problem here is that browser support for the relative-width syntax of the col element is thin, most of all in IE. The spec says that the width attribute of the col element can be specified in three different ways:

1. number of pixels
2. percentage of parent width
3. proportion of parent's width relative to other columns

It's that third flavor that this table was using, and that's the one that's poorly supported. Support for the second syntax is more reliable, but it doesn't work in IE with the table set up the way it was, with all of the left-most columns set to colspan=2. If you set up the table this way, it works in IE:

• specify 5 columns

• width for first column set to 33.3%

• width for all other columns set to 16.7%

• colspan=2 used only where the column is really divided on other rows

The table in question has been modified, so it's no longer a good example for this problem.

BZDATETIME::2011-05-12 09:01:52
BZCOMMENTOR::Robin Juthe
BZCOMMENT::5

(In reply to comment #4)
> The table in question has been modified, so it's no longer a good example for
> this problem.

The current Table 5 in the Genetics of Breast and Ovarian Cancer summary (CDR62855) is a good example:

http://www.cancer.gov/cancertopics/pdq/genetics/breast-and-ovarian/HealthProfessional/Table5

BZDATETIME::2011-05-12 09:20:58
BZCOMMENTOR::Bob Kline
BZCOMMENT::6

That table looks funky because of a bug in the data: the third header column has a colspan of 3, but it should be 2.

BZDATETIME::2011-05-12 16:23:57
BZCOMMENTOR::Volker Englisch
BZCOMMENT::7

(In reply to comment #6)
> That table looks funky because of a bug in the data: the third header column
> has a colspan of 3, but it should be 2.

The colspan=3 for the table is due to an oddity in the XML document.
The table has been defined with 5 columns named in this order
column 1 - col1
column 2 - col2
column 3 - col03
column 4 - col3
column 5 - col5

The colspan for the table in XMetaL is defined by specifying at which column the span starts and ends. For this table we have three spans:
First span: col1 to col1 --> one column
Second span: col2 to col03 --> two columns
Third span: col3 to col5 --> two columns

I believe that the code on Gatekeeper creating the table is interpreting the span of the tables from the column named "col3" (fourth column) to the column named "col5" (fifth column) as three which results in the poor display on Cancer.gov.
We have fixed the column names in the CDR and if I'm right a hot-fix of this summary will correct the problem.

BZDATETIME::2011-05-17 14:34:31
BZCOMMENTOR::Volker Englisch
BZCOMMENT::8

We've decided that we would want to try modifying the vendor filters such that the specified proportional column width (i.e. "2*") would be converted to a percentage format. We would, for instance, change the following column width specifications
<tgroup cols="2" >
<colspec colnum="1" colname="col1" colwidth="1*"/>
<colspec colnum="2" colname="col2" colwidth="2*"/>

to the following
<tgroup cols="2" >
<colspec colnum="1" colname="col1" colwidth="33%"/>
<colspec colnum="2" colname="col2" colwidth="66%"/>

BZDATETIME::2011-09-08 15:17:30
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

This comment is a little off topic but I don't want to forget it:
Robin had asked if it could be possible to use background colors for table cells.

After looking at our DTD I see that it includes two attributes, TabStyle and TGroupStyle, which may allow us to specify styles. The values for these attributes, as far as I understand the information I can find, would specify a style name. This could be a possibility to somewhat style a table but it would not provide the ability to style a table on a cell level.

A solution that I could imagine would be a new attribute to allow either the entry of a class name or the entry of CSS. However, a change like this would require the Gatekeeper code to be modified. In addition to that I wouldn't know if the Cancer.gov designers would allow any CSS to be "passed through" to Cancer.gov.

BZDATETIME::2012-02-23 17:43:45
BZCOMMENTOR::Volker Englisch
BZCOMMENT::10

As discussed earlier we wanted to see if it were possible to use the column width as specified for a table in XMetaL and convert it to a percentage value in the vendor output which would be understood by a browser once converted to HTML.

Short answer: Yes.

Long answer:
My initial tests revealed that the ColWidth attribute, which is part of the ColSpec element, does not get touched by the Cancer.gov/Gatekeeper processing.
Whatever value is listed here is passed through to the width attribute that defines the column width in the HTML Col element.
This means our idea of converting the 1*, 2*, 3* values into percentages can work for specifying the column widths of a table.
I was able to update our vendor filters by creating the sum of "column units" for a table and then specifying the column width as percentage of the entire table as
100 / sum(column units) * (current column units)

This has been implemented on MAHLER and I have looked at a few summaries with lots of tables. Given the fact that I'm looking at MAHLER's data I thought this is looking pretty good.

So far I've identified three problems:
a) Because this has been implemented as part of the Vendor Summary Filter
this is currently only available for summaries. If we want the same
functionality to be available for other doc types (Drug Infos?) I will
need to move the templates.

b) When a table gets created with a footer and the footer does not span
across the entire table the "column footer" does not move with the
adjusted column size.
For instance, a table with two columns and a footer looks like this before
the columns are adjusted:

These will be displayed on Cancer.gov after the columns have been
adjusted like this:
|----------|---------------------------------------|
| Short | Very very long Header |
|----------|---------------------------------------|
| one | eins |
| two | zwei |
|===========|========================================|
| English | German (footer) |
|----------|---------------------------------------|

Note that the German footer text is not moved as all of the other text.
I believe this is either a problem with the implementation of tables on
Gatekeeper or the requirements for the Cancer.gov team was incorrect
or incomplete.

c) We will need to decide how to address such a change in the vendor output
since our licensees might use the current specifications for column widths.

This is ready for review on MAHLER.

BZDATETIME::2012-03-01 16:41:30
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

If and when we decide to put this in production we will have to remember to coordinate the load with Cancer.gov. Since every summary containing a table will be updated the first load will create a multiple hour processing job for Gatekeeper.

This note may help me to remember.

Also, I've looked at the Gatekeeper code with Blair and confirmed that the ColWidth attribute value is copied as is provided that it doesn't contain the asterisk '*'.

BZDATETIME::2012-03-06 15:12:15
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::12

(In reply to comment #10)
> This is ready for review on MAHLER.

We tested this on Mahler and it seems to be working very well. The changes are displaying as expected in pub preview.

BZDATETIME::2012-03-14 18:49:29
BZCOMMENTOR::Volker Englisch
BZCOMMENT::13

I ran a diff report on FRANCK and it appears that the conversion of the '*' notation into percentages for the tables is working nicely.
However, while I was looking at the changes I noticed that there are tables that will change its appearance due to the way the table in the CDR has been 'tricked' to look right for the user. For instance, there are a few tables for which the column width has been set to '0*'. This will now converted to a column width of '0%' and will confuse the browser because their is more data available than columns. Please see Table 3 for CDR256636 (Depresión - HP) on Cancer.gov and compare it with the table in PP on FRANCK.
Also, there are tables with table widths specified as '1.04*' for instance when this probably should have been '1*'. This is not a problem with the display but if somebody like me wonders why the column widths are slightly different within a table this would be one reason.

BZDATETIME::2012-03-14 18:53:08
BZCOMMENTOR::Volker Englisch
BZCOMMENT::14

I'm attaching the diff report for the filter changes. This includes more than just the table column width changes so I tried to filter out as much as possible of what is not related to the column width.

The output would allow to identify tables that may need additional tweaking after the filter changes have been moved to production.

Attachment TableCols.txt has been added with description: Diff Report Output for Column Width Changes

BZDATETIME::2012-03-16 16:04:49
BZCOMMENTOR::Volker Englisch
BZCOMMENT::15

The following filters have been copied to FRANCK and BACH:
CDR271370 - Module: Vendor Filter Templates - R10347
CDR000157 - Vendor Filter: Summary - R10347

I've also updated the filter sets on BACH to make the adjustment for the QC reports to display insertion/deletion markup for content within summary modules.
The following filter sets have been created or adjusted:

• Denormalization Summary Module Set (new)

• Denormalization Summary Set

• QC QD Summary Patient Set

• QC QD Summary Patient Set (Bold/Underline)

• QC QD Summary Set

• QC QD Summary Set (Bold/Underline)

• QC Summary Patient Set

• QC Summary Patient Set (Bold/Underline)

• QC Summary Set

• QC Summary Set (Bold/Underline)

• Vendor QC Summary Set

• Vendor Summary Set

Please verify the changes on Cancer.gov after tonight's publishing job.

BZDATETIME::2012-03-19 11:51:00
BZCOMMENTOR::Volker Englisch
BZCOMMENT::16

I've looked at a number of summaries on Cancer.gov to ensure that the column width is now specified using a percentage value on Cancer.gov. All summaries that I looked at looked good.

BZDATETIME::2012-04-19 14:01:38
BZCOMMENTOR::Volker Englisch
BZCOMMENT::17

Closing issue as discussed at today's status meeting.