nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Upgrade BIRT Viewer 2.5.2 to 3.7.2 Under Tomcat

jjfeigal

I am in the processing of upgrading our BIRT viewer under Tomcat 6.0 from 2.5.2 to 3.7.2 and have been testing all of our existing BIRT reports before deploying the new viewer into production.

We have a web application that submits a URL that invokes the BIRT viewer with a user selected report. Reports output is generated in HTML format in a new browser window by default and the user has the option to then print them in their desired format.

First Issue
At the end of a report a solid line is displayed. In some reports there is also a solid line displayed on the right hand side of the report.

At this point in time, all of the reports were developed with BIRT designer 2.5.2 or earlier. Thinking that the lines might be report border related, I've modified a couple of reports with BIRT designer 3.7.2. I've added borders and then removed the borders without any luck of getting rid of the unwanted lines.

Second Issue
We have developed some CSS that we use to format report headings in a consisent format. On some of our crosstab reports we seem to be losing padding or margin at the bottom of the heading preceding the top of the crosstab.

Third Issue
On the crosstab reports, the report is cutoff in the middle of the last column.

None of these issues existed with the 2.5.2 viewer. Are there any explanations as to why the issues exist with the 3.7.2 viewer? Any suggestions how to debug the problems.

Attached is a screen capture that shows the issues.

I'm almost to the point of modifying JSP and JS code in the viewer to default the report print format to PDF instead of HTML per formum postings by Jason Weathersby, although the report heading issue still exists for PDF format. Also, I can add __format=pdf to the URL invoking the viewer to initially display a PDF to get by the horizontal and right vertical line issues.

Find more posts tagged with

Comments

JasonW

Was your screenshot taken in the designer preview or the deployed viewer? I believe the line was added in the viewer? When I display a report the line shows for a moment and then is replaced with the content. Can you reproduce the issues with the sample db and post the report?

Jason

jjfeigal

Jason

The screen shot was taken from a deployed viewer installed under Tomcat.

I've also created the extra lines in the Designer in Preview mode and in the Web Viewer.

I have tried to attach a zip file containing a report that I got from you directly or via a BIRT website a long time ago (JasonWeathersbyFirstReport.rptdesign), but when I reply to this post I get "500 - Internal server error. There is a problem with the resource you are looking for, and it cannot be displayed". Running this report generates the extra lines, too.

Attached is a screen shot of the Web Viewer output for the JasonWeathersbyFirstReport.

JasonW

Send it to my email at jasonweathersby at windstream dot net

Jason

jjfeigal

After further research, I can add the following information related to each of the original issues.

Issue 1 - Lines on the bottom and right side of a report

Jason has helped me look at the issue from another perspective.

Most if not all of my development is with IE because of some limitations with our web application that we have integrated with our BIRT reports. Also, I primarily work with the 32 bit version of IE9 to deal with some other legacy issues which we hope to soon have resolved.

I have pasted a URL to generate one of the reports in question into various browsers this morning with these results:

IE9 - 64 bit - lines are displayed
IE9 - 32 bit - lines are displayed
Chrome in IE mode - lines are displayed
Chrome not in IE mode - no lines are displayed but the report is truncated on the right side and the bottom.
Firefox - no lines are displayed and the report looks great

For the BIRT Viewer browser window in IE9, the Browser Mode is IE9 Compatibility View and the Document Mode is IE7 Standards. Our web application (based on IBM Lotus Domino) runs with a Document Mode of Quirks Mode. I'm not sure why the BIRT Viewer is running with IE7 Standards Document Mode. Might this be a related issue?

Does the BIRT Designer Web Viewer use the system's default browser? If not, how is the report rendered? Same question for Preview mode in the BIRT designer. I see the lines in the BIRT designer, too.

Here is a URL that identifies a generic issue "Overflow Problem in Trident in Document Mode: IE7 Standards" related to coding CSS for position:relative.
http://technical.allofe.com/contentm/easy_pages/easy_page_view.php?sid=62&page_id=246&blueprint_id=26

If I do a View Source for the BIRT report output with the lines I see <DIV ID="display0" STYLE="display:none;width:250px;position:relative;overflow:auto"></DIV>

Issue 2 - Report header formatting
I increased the height of the header on the master page and a report displays fine.

Issue 3 - Crosstab truncation

I placed the crosstab inside a single cell grid, removed right and left margins from the crosstab, added right and left margins to the grid, and the report displays fine.

Hopefully, an explanation and work around can be identified for issue 1 so that I can install the 3.7.2 viewer in our production environment.

jjfeigal

I've received the following email response from Jason Weathersby regarding Issue 1. Using the IE developer tools I verified Jason's analysis. Bugzilla bug 385546 has been logged.

John,

After much pain I think I know what the issue is. I am not certain if you have developer tools on your ie instance but the issue appears to be with ie9 having an issue with the css rules attribute. I used the developer tools to remove this attribute and it appears to work. Unfortunately that attribute is written by the html emitter in code:

writer.attribute( "rules", "none" );

Can you try the dev tool just to verify. This may require logging a bug. One thing that does not make sense is that the value is set to none which should not display.

Jason