CDR Tickets

I experimented with two ways to limit the topic to titles of published
summaries:

 1. Only take Summaries that had titles in the query_term_pub table.

    This limits us to publishable versions, but doesn't exclude
    something for which a publishable version has been created but not
    yet published.  That is probably a non-issue since any Summary made
    publishable for the first time will be published that same night.

 2. Only take Summaries that are actually published.

    By "actually published" I mean that we have a row in the pub_proc_cg
    table that says we have pushed a version of this Summary to
    cancer.gov.  This excludes any document that is not now on
    cancer.gov.

Trying them both out I find the difference is the two records that are
currently marked as Modules, i.e.,:

    738176      Peutz-Jeghers syndrome (PJS) [Module]
    743132      Lynch Syndrome and Breast Cancer Risk [Module]

Peutz-Jeghers actually made it to cancer.gov at one time but was pulled
back, presumably because it's a module.

Which approach should I take?

{noforce}
The interface to Word is turning into the hard part of this task.

I did a number of experiments, not modifying the program, just creating
HTML sample files to view in the browser and then cut and paste into
Word.

I first tried creating the output as a list. That wasn't hard to do. I
could also style the list with CSS to eliminate all bullets and get the
bold font on the main list items (topic or board member) and indentation
on the secondary (board member or topic).

So far so good.

Then I cut and pasted it into Word.

The results were different in different browsers.

None of the browsers produced a list output in Word that looked just
like it did in the browser.

Internet Explorer 9, 10 and Chrome 29 copied some but not all of the
CSS styling output. Specifically, bullet styles were lost with all
browsers.

Firefox 16 and 23 didn't seem to copy any CSS styling.

With all of the browsers Word recognized that I was pasting in a
list, but it applied its own bulleting style to the list and ignored
the CSS entirely.

I was able to produce the most accurate paste into Word from all
browsers except IE9 by using HTML markup to produce the bold face plus
non-breaking spaces to produce the indentation that we want. That
produces antique but simple and perfectly legal HTML and also produces a
Word document that is easy to work with. If bulleted lists are
undesirable, that's probably the best way to go.

It's getting late tonight. I'll attach some example files next Tuesday
if desired.
{noforce}

Thanks, Alan.

Given that we plan to add many more modules in the future, I think we should take approach #1. If I understand correctly, the two modules showed up when the requirement was for a publishable version rather than a published document that reached Cancer.gov. Is that right?

As for the report format, I think it would be helpful to look at a few examples next week.

This file uses nested lists to create a list of lines within entries in a larger list.

There is a bit of css, primarily to see how the browsers handle css when cutting and pasting.

This file has no html list elements. It uses "strong" markup to mark the headings in the outer list and strings of spaces to indent the inner lists.

I'll use approach #1, using the query_term_pub table to select publishable trials.

I notice that this issue is not marked for inclusion in the upcoming CDR release. Should it be?

I have completed changes on DEV to handle published only or all
summaries in the report.  The way I handled the query_term tables is as
follows:

    For selecting Summaries:

        Use the query_term_pub table if published only is checked.

    For selecting everything else, mainly board members but also
    anything used in creating picklists for the user interface:

        Use the regular query_term table.

The reason for this is that, if there is a change in persons associated
with a Summary, I figured we wanted the latest version in the current
working Summary document, not what is in the most recently published
version of the Summary document - which could occasionally be a little
out of date.

All that remains to do is to modify the output formatting for improved
cut and paste into Microsoft Word.

To do that, I need a decision about whether the board managers would
prefer an html bulleted list style output, or a set of paragraphs, each
containing a bold faced header line with indented lines beneath it.

To see the alternatives, try clicking on each of the attached html files
and then cut from the html and paste into Word.

When I did it with Word 2010 and various browsers I got acceptable
looking output either way, but I didn't find any way to suppress the
bullets in the Word lists even though my CSS made the lists non-bulleted
in the html.

If you prefer the bullets, let's go with the list style.  If you prefer
to not to have bullets I think the other approach is better.  At least
that's how it appeared in my tests with Word 2010.

I think the bulleted/indented version looks cleaner, so let's go the example in "listlist". However, please do not use colors - just black font with the summary titles in bold. Please also add a blank line in between summaries (as in the other attachment). Thanks!

I've fiddled and twiddled with this and finally implemented a hybrid
approach that has lines of main headings, not in a list, with
interspersed lists of the inner headings.  There are no bullets in the
HTML output but Word does produce bullets for the inner lists.

It's very easy for me to change this if the Robin decides that the outer
headings should also be bulleted.

The Summary CDR IDs pose additional problems that I didn't address in
the two sample HTML files that I posted.  I thought that they would be
most useful in the HTML reports used by board managers and not so useful
in the Word documents that go out to board members.  I therefore
optimized the appearance to look best in the HTML report.  They're
readable in Word but the techniques used in HTML and CSS to get nice
alignment don't get interpreted by Word so the lines are "ragged" when
there are different sized CDR IDs (e.g. 12345 vs. 123456) rather than
nicely aligned, and the spacing is not as wide.

I can make the alignment better in Word if I use fixed size CDR IDs,
e.g.,:

    CDR0000012345
    CDR0000123456

But with that, although the formatting is nicer, the CDR0000 is just
noise.

It's ready for testing on DEV.  Please ask for formatting tweaks if you
want them.  They're likely to be straightforward.  If they're hard to do
I'll ask before spending a lot of time on them.

The Summary CDR IDs pose additional problems that I didn't address in
the two sample HTML files that I posted.

I would suggest to add the CDR-IDs after the Summary in parenthesis like this. That way it would look a little cleaner IMHO.

Adult Soft Tissue Sarcoma Treatment (62820)

• Berman, Russell

• Truong, Minh

I agree with Volker's suggestion to place the CDR IDs in parentheses after the summary title. Otherwise, this looks great. Thanks.

The CDR IDs in parens are implemented on DEV and are in svn.

I noticed that, when copying to Word, not only are bullets added to the list items, but the bolding is removed from the main headings above each sublist. I can fiddle with that if desired. It might be easy to fix.

Interestingly, I was testing at home where I use Libre Office instead of Word. LO respected the CSS for lists and did not add bullets to the list items. However it too lost the bolding.

I verified that the CDR IDs are in parens when the option is selected.

While it would be nice for the bold font to be preserved, it isn't something that is worth spending much time on. If it appears to be a quick fix, great, but if not, we'll be happy to promote this as is so I'm marking this QA verified. Thanks!

Alan: you said the bold font preservation might be a quick fix. Did you investigate to determine if that were true?

> Alan: you said the bold font preservation might be a quick fix. Did you investigate to determine if that were true?

I seem to recall that that would work. I'll check it tomorrow. I think that it's likely to be very little work.

I made the change and tested in Firefox, IE, and Word. I think it does what we want.

The modification is on DEV and in svn.

Verified the bold font preservation on DEV.

Verified on QA.

Verified in production.