CDR Tickets

BZDATETIME::2012-03-28 18:56:27
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

It looks like we forgot to test if the adjustment of the table column width from the '*' notation to percentages would work for the mailers.
The error message says:
u'Illegal ColWidth: 50.00%'

Maybe we can preserve the '*' notation for the mailers and strip it with final cleanup filter?

BZDATETIME::2012-03-29 14:18:47
BZCOMMENTOR::Bob Kline
BZCOMMENT::2

Passing this on to Volker.

BZDATETIME::2012-03-30 15:06:08
BZCOMMENTOR::Volker Englisch
BZCOMMENT::3

(In reply to comment #2)
> Passing this on to Volker.

You didn't. :-)

The idea was to leave the ColWidth attribute with *-notation as is, create a new attribute containing the %-notation and then remove the *-notation attribute and rename the %-notation attribute using the final vendor cleanup filter.
Unfortunately, this won't work.
For all of the document types we're publishing the mailer filter set includes:

• Denormalization DocType Filter

• Vendor Filter: DocType

while the Vendor filter set includes:

• Denormalization DocType Filter

• Vendor Filter: DocType

• Vendor Filter Final/Cleanup

but not for Summaries. The Mailer Summary Set includes the final vendor filter set - and then some.
This means we will only be able to continue our idea if we're creating an additional table column attribute in the DTD for the %-notation and modify the filters to use this new attribute instead of the existing ColWidth attribute.
This may be OK for data send to Cancer.gov but we would definitely need to modify our post-processing filters to remove/rename the new attribute so that the licensees continue to receive just the one attribute including the %-notation.

The other option I see would be to modify the mailer software to convert back the %-notation into something that LaTeX can handle.

Or maybe it would be possible for the mailer software to pass a parameter to the filter processing that could be used in order to apply the conversion of the *-notation to the %-notation or not based on the existence of this parameter but I do not know if this is possible.

If there are other options I haven't thought of those yet but I'm willing to listen.

BZDATETIME::2012-04-02 12:59:19
BZCOMMENTOR::Robin Juthe
BZCOMMENT::4

I'm raising the priority on this issue since Bonnie is unable to send mailings until it is fixed. Thank you!

BZDATETIME::2012-04-02 13:26:17
BZCOMMENTOR::Bob Kline
BZCOMMENT::5

I've installed a modification to the mailer software on Mahler. Can someone test there (or give me a summary on Mahler that triggers the error)?

BZDATETIME::2012-04-02 13:27:52
BZCOMMENTOR::Volker Englisch
BZCOMMENT::6

Any summary with a table will do, like Breast Cancer Treatment HP (CDR62787).

BZDATETIME::2012-04-02 13:51:47
BZCOMMENTOR::Bob Kline
BZCOMMENT::7

Looks OK to me, except I had to move the fix to Franck, because of the MiKTeX bug Volker's working with on Mahler. Ready for user testing (on Franck).

BZDATETIME::2012-04-02 13:58:28
BZCOMMENTOR::Volker Englisch
BZCOMMENT::8

I see an error message:
Total of explicit ColWidth too large
when using CDR62902.

BZDATETIME::2012-04-02 14:00:37
BZCOMMENTOR::Robin Juthe
BZCOMMENT::9

I'm also getting error messages for the following summaries: CDR299612, CDR62890, and CDR62738. The mailer of CDR517309 (which is full of tables) came up fine.

BZDATETIME::2012-04-02 14:02:27
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::10

The mailer for 62787 came up fine on Franck for me as well. But Bonnie got the same error when she ran a couple of them on Franck also.

BZDATETIME::2012-04-02 14:22:50
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

(In reply to comment #8)
> I see an error message:
> Total of explicit ColWidth too large
> when using CDR62902.

I'm wondering if this could be a rounding error. When I create the percentages I'm converting the column width to a number and it may be possible that the total width of the specified columns could become > 100%.
Should I double-check this?

BZDATETIME::2012-04-02 14:24:34
BZCOMMENTOR::Bob Kline
BZCOMMENT::12

(In reply to comment #8)
> I see an error message:
> Total of explicit ColWidth too large
> when using CDR62902.

That's because if you add up the percentages for the seven columns in the table where the error happens, you get slightly higher than 100% (1.0002). Rounding errors in the filter need to happen in the other direction, if they happen at all. Or I can automatically shave a tiny bit from any column width specified by a percentage.

BZDATETIME::2012-04-02 14:25:01
BZCOMMENTOR::Bob Kline
BZCOMMENT::13

(In reply to comment #11)
> (In reply to comment #8)
> > I see an error message:
> > Total of explicit ColWidth too large
> > when using CDR62902.
>
> I'm wondering if this could be a rounding error. When I create the percentages
> I'm converting the column width to a number and it may be possible that the
> total width of the specified columns could become > 100%.
> Should I double-check this?

Yep, that's what's happening (see my previous comment).

BZDATETIME::2012-04-02 14:34:22
BZCOMMENTOR::Bob Kline
BZCOMMENT::14

(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #8)
> > > I see an error message:
> > > Total of explicit ColWidth too large
> > > when using CDR62902.
> >
> > I'm wondering if this could be a rounding error. When I create the percentages
> > I'm converting the column width to a number and it may be possible that the
> > total width of the specified columns could become > 100%.
> > Should I double-check this?
>
> Yep, that's what's happening (see my previous comment).

That table works now. I'm shaving .5% of the total table width from each column specified by a percentage width. I can make the adjustment smaller, but that would increase the likelihood of cumulative rounding errors causing a failure. Let me knock it down to .1% of the total table width and have the users test until they're satisfied that the errors have disappeared. If so, we can use this fix, if not, we can bump the adjustment up until it's working for all the tables. Or we could just put it in production and react to errors as they occur.

OK, it's at .1% now. Ready for (more) user testing.

BZDATETIME::2012-04-02 14:47:22
BZCOMMENTOR::Volker Englisch
BZCOMMENT::15

Since we're limiting the tables to a maximum of 7 columns, if I remember correctly, and the rounding error cannot be greater than 0.01% we shouldn't encounter a total error of 0.07% at any time.

I will still look if it's possible to round down in XSLT to make this right. I believe the function I'm using formats real numbers by dropping digits.

BZDATETIME::2012-04-02 15:09:50
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::16

(In reply to comment #14)

>
> OK, it's at .1% now. Ready for (more) user testing.

It worked for me for all the individual mailers I've ran so far. However, Bonnie continues to report errors when she runs a mailer job on Franck. The error does not appear to be related to the current issue though.

[Errno 2] No such file or [Errno 2] No such file or directory:'d:cdr/mailers/output/PrintFilesForJob9127.tar.bz2'

If the message is indeed unrelated, I believe we can promote the changes to Bach.

BZDATETIME::2012-04-02 15:34:28
BZCOMMENTOR::Bob Kline
BZCOMMENT::17

(In reply to comment #16)

> Bonnie continues to report errors when she runs a mailer job on Franck. ....
>
> [Errno 2] No such file or [Errno 2] No such file or
> directory:'d:cdr/mailers/output/PrintFilesForJob9127.tar.bz2'

That's odd. I can see the file in the directory, and I am able to retrieve the file using the port 80 interface which the script uses to retrieve the job output. Are you sure she's not running the batch file for Bach when she tries to get the job she created on Franck? Perhaps Volker can walk down the hall and look over her shoulder to see what she's really doing.

BZDATETIME::2012-04-02 15:36:08
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::18

(In reply to comment #17)
> (In reply to comment #16)
>
> Perhaps Volker can walk down the hall
> and look over her shoulder to see what she's really doing.

I think this is a good idea since it has happened in the past before.

BZDATETIME::2012-04-02 16:28:51
BZCOMMENTOR::Volker Englisch
BZCOMMENT::19

(In reply to comment #17)
> Are you sure she's not running the batch file for Bach

It's all good now. I was able to run the mailer preview on FRANCK with the summaries that failed earlier and the error message Bonnie saw after the table fix were due to the fact that the program runprintjob.cmd is looking for the mailer job on BACH if a hostname hasn't been specified.

BZDATETIME::2012-04-02 16:31:21
BZCOMMENTOR::Bob Kline
BZCOMMENT::20

(In reply to comment #19)

> It's all good now. I was able to run the mailer preview on FRANCK with the
> summaries that failed earlier and the error message Bonnie saw after the table
> fix were due to the fact that the program runprintjob.cmd is looking for the
> mailer job on BACH if a hostname hasn't been specified.

Right. Didn't we make her separate scripts for Franck and Mahler?

BZDATETIME::2012-04-02 16:39:44
BZCOMMENTOR::Volker Englisch
BZCOMMENT::21

I did not look at the content of the scripts on her hard drive but I do think I saw a script named runprintjobFranck.cmd.

BZDATETIME::2012-04-02 18:28:57
BZCOMMENTOR::Volker Englisch
BZCOMMENT::22

(In reply to comment #15)
> Since we're limiting the tables to a maximum of 7 columns, if I remember
> correctly, and the rounding error cannot be greater than 0.01% we shouldn't
> encounter a total error of 0.07% at any time.

I was able to make changes to the filter and ensure that the sum of all table columns will never be greater than 100% and the error for each table column will never be greater than 0.001% by using the following formula:
[floor(colwidth/tablewidth * 100 * 1000)] / 1000

The changed filter is
CDR271370 - Module: Vendor Filter Templates
but we'll be unable to move this to production until after the WCMS 2.4.1 release.

BZDATETIME::2012-04-03 10:52:18
BZCOMMENTOR::Volker Englisch
BZCOMMENT::23

Bob and I discussed that we would put his change in the mailer program in production to fix the current problem and because the fix in the filter cannot be copied to production until next week.
Next week, after the filter changes have been put in production, Bob will remove the part of the mailer program that's removing 0.1% from each column.

Bob copied the change to the mailer to BACH and Bonnie was able to run the acupuncture summary mailer successfully.

BZDATETIME::2012-04-11 10:02:57
BZCOMMENTOR::Bob Kline
BZCOMMENT::24

(In reply to comment #23)

> Next week, after the filter changes have been put in production, Bob will
> remove the part of the mailer program that's removing 0.1% from each column.

Please let me know when the filter changes are in place.

BZDATETIME::2012-07-23 16:59:46
BZCOMMENTOR::Volker Englisch
BZCOMMENT::25

(In reply to comment #24)
> Please let me know when the filter changes are in place.

The filter changes are now in place.

BZDATETIME::2012-08-09 15:11:06
BZCOMMENTOR::Bob Kline
BZCOMMENT::26

The hack to shave off .1% of each column's width has been backed out of the mailer software. Once you are satisfied that the mailer's still work correctly, this issue can be closed.

BZDATETIME::2012-08-23 13:09:40
BZCOMMENTOR::Bob Kline
BZCOMMENT::27

I put the fudge back in at Volker's request.

BZDATETIME::2012-08-30 15:33:39
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::28

It was decided in today's meeting to close this issue. Marking it as Resolved.

BZDATETIME::2012-08-30 15:34:04
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::29

Issue Closed.