Issues with jasperreports 2.0.3

[itchytoes]

Hi --

 

I've been using JasperReports since version 1.3.0. The most recent version (before this 2.0.3) was 2.0.1. I've never had to change any reports or anything from upgrade to upgrade, but this latest 2.0.3 has given me problems.

 

One of my biggest issues is with my boxed tables. Most of my reports involve tables with borders on all the cells. I don't know if this is a trick or not, but it has worked till now -- I would specify a border for all sides of the box in my style element. Then I would "cheat" by specify the x and y locations as 1 pixel before the one I need and add one to the width and height, and I can use the same style for every cell, and the boxes are nice thin borders. (For example, a single-row detail would have y="-1" instead of "y=0". Now, with this 2.0.3, my lines have become thick and look bad.

 

Even worse, a couple of reports now cause Adobe reader to give "Illegal operation inside a path" error when I try to view the PDF file.

 

Is it because something changed with the way the cell borders are handled? I dread having to redo all my reports to deal with this. Again, I've had no problems with all the releases up to now.

 

Thanks

 

Betty

[itchytoes]

Hi

 

I downloaded 2.0.2 to see what happens, and the reports are fine. My boxed cells look as before and I have no

Adobe reader errors.

 

So, something happened between 2.0.2 and 2.0.3.

 

 

 

Betty

[teodord]

Hi,

 

Yes, something happened in JR 2.0.3.

We have changed/improved the way we draw lines and borders by allowing any combination of line style and line width, not only the fixed 5 combinations: Thin, Dotted, 1Point, 2Point and 4Point that we had before.

For instance, now you can have dashed lines that are 0.1 pixel thick.

 

To support this, slight changes were made to the way borders were drawn. Today, all borders, regardless of thickness are drawn half inside and half on the outside of the box. This means that elements that touch edges, will have their borders overlap perfectly.

Before 2.0.3, thin borders of adiacent elements resulted in a combined border of 1 pixel. This is no longer the case.

 

However, what you describe does not seem to be the case, so please post your JRXML, or a simplified version of it to this thread, so that we can also investigate the error you mentioned with the PDF export.

 

Thank you,

Teodor

[itchytoes]

Hi --

 

I will post some sample jrxml files after I return to work on Jan 2.

 

In the meantime, I do want to mention that my Adobe reader error occurs on a couple of reports that have subreports. It does not happen for all reports with subreports, just a couple. I don't think it has much to do with the cell borders because I stripped most of the report out, but there's something about the subreport that's killing it. (And yes, the subreport runs fine on its own, and it was fine before 2.0.3)

 

Regarding my formerly thin cell borders -- they appear to be 2 points now instead of 1 in most places. I will have to provide a sample file for that.

 

Betty

[vincewebb]

Hello

I have seen the same error "Illegal operation inside a path". Thrown up by Adobe 7 when viewing a pdf generated by jasperreports-2.0.3.jar. Adobe 8 displays the pdf OK.

 

I have substituted jasperreports-2.0.2.jar and so far all is well.

 

This report was originally generated using jasperreports-1.2.5.jar which was fine until a colleague updated a sub-report using IReports 2.0.2. This was what prompted me to install the latest jar file.

[itchytoes]

Hi -- I've attached a sample cells.jrxml report which illustrates my cell border problem. If you run it with the jasper2.0.2 jar files, the lines are nice and thin everywhere. With 2.0.3, the lines in the middle that join 2 cells are thicker.

 

I am using itext-1.4.8.jar (for some other reason) but I don't think that matters. I think I tried the itext-1.3.1.jar that came with jasper and the same thing happens.

 

I would really, really, really like it if my existing jrxml files don't need to be changed for this 2.0.3 because I have LOTS of them.

 

I will work a sample on the Adobe Reader error with a subreport next.

 

Betty [file name=cells.jrxml size=1823]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/cells.jrxml[/file]

[itchytoes]

Hi -- I've attached a zip file with one report and one subreport that causes my Adobe PDF error if I generate the PDF using jasperreports 2.0.3. It is fine if I use jasperreports 2.0.2.

 

The report (PDFError.jrxm) just has a pageHeader that calls the SubReport and a pageFooter that has a line. If I take out either the subreport or the line, it works fine. It dies with both elements in the report.

 

I am using Adobe reader 7.0. I did not try with Adobe 8.0 yet.

 

Thanks

 

Betty [file name=PDFError.zip size=1630]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/PDFError.zip[/file]

[teodord]

Hi,

 

I can confirm you that the change you see in your cell border example was intentional in JR 2.0.3 and not accidental, or a bug.

 

Sooner or later we had to give up the way borders were drawn because it was inconsistent and not scalable.

Thin and 1Point borders were drawn on the interior of the element area, while 2Point and 4Point borders where drawn half on the inside and half on the outside of the element area. So, if you wanted to perfectly overlap 2Point and 4Point borders, you had to make the element touch edges, while for 1Point and Dotted borders, the elements had to overlap 1 pixel. It was impossible to make Thin borders overlap, like you did for your 1Point border cells.

 

Now all borders are drawn half on the inside and half on the outside, regardless of their thickness. Borders perfectly overlap if elements touch edges.

 

I'm sorry if you have to change your templates, but maybe you should not upgrade to newer JR, if you don't need its newer features.

 

I think that the idea to have all your cells with border all around them and making elements overlap 1 pixel so that the 1Point border looks like a single line border was not a good idea, in the first place.

Overlapping elements do not work in grid exporters, so you would have had a problem right away if you exported to HTML or XLS. The solution is to make the elements touch edges and use the side border of only one of the cells, not both.

If you would have done so, you would not have this problem in JR 2.0.3.

 

The changes made in JR 2.0.3 will allow us to introduce other types of borders more easily, while preserving the way borders are drawn for the future.

 

Thank you,

Teodor

[teodord]

Hi,

 

The errors in PDF caused by subreports were indeed a bug introduced in JR 2.0.3 which was then solved in the SVN head version.

The fix will be part of the next JR release, in one or two weeks from now.

 

Thank you,

Teodor

[itchytoes]

Hi --

 

Okay -- thanks. I used a piece of graph paper and blackened squares and half squares and I understand your explanation. I also knew my reports do not work in HTML but that was not a requirement. I also did it that way with the overlapping elements because it seemed to simplify the reports. I did worry that something would fail at some future version. Oh well.

 

Have you had any luck with the Adobe error (in the other example)?

 

Betty

[C-Box]

Hi,

 

good to read that topic before switching to 2.0.3

 

I also have hundreds of jrxml files at different customers that uses (sometimes less, sometimes more) borders to simulate tables.

 

As I have an own "reorganize" function that loops through all used jrxml's within our database/application, parses the JRDesigns for all JRElements, validates them against some certain rules, recompiles them and stores it back to database.

 

I could imagine to remove with that feature all left borders (except first element in column) and just use the right border if the space between two (static)textfields at one line is zero and the element has borders actually. (so the mentioned trick of Betty told). So it should look before and not thicker than now in JR 2.0.3

 

Should work - at least I dream of it ;) - perhaps I'll give it a try tomorrow.

 

just my two cents

C-Box

[itchytoes]

Hi --

 

I think one of the reasons I use this overlapping boxes trick has to do with the difficulty in getting the top and bottom cell borders working. I believe I can easily deal with left and right borders and just using one border from adjoining cells. On the top border, however, if I have no border, then I have trouble with the first table row on a page. I can't always use a pageHeader because the page breaks can occur in different parts of the report which display different types of stuff (including different tables). If I specify a top border for my elements but omit the bottom border, I have trouble figuring out how to force the border on the last row of a page. Page footers don't seem to do it right, and the last row of a page is not the same type of thing. This overlapping trick always gets me top and bottom borders.

 

I've become better at JasperReports over time. Maybe I will think of something now that I never thought of before, or maybe there is some attribute that I can set that I never saw before. Does anyone have any suggestions?

 

Betty

[C-Box]

When I remember right, I used the column header and column footer band to ensure that the beginning of the table has a top line and the end has a bottom line.

 

The bottom border works for separating detail rows or also a horizontal line between them.

 

The column bands are printed at every page and if the last page is not filled full the column footer is floating to the end of the last detail row.

 

hth

C-Box

[itchytoes]

Hi --

 

I believe I'm going for the longest number of messages on one post :)

 

Okay, I have tried it out with jasper 2.0.3, and I realize now with the cell borders being drawn 1/2 inside and 1/2 outside, I can always specify all sides of borders for my cells and they meet up correctly on adjoining cells. I no longer have to do the overlapping trick -- I just start at the x and y I want and reduce my size back down by 1. Everything will look nice. Once I do this, my cell borders will look thick using jasper pre-2.0.3, but that's okay -- I will change the jrxml files and the jars at the same time.

 

Betty

[ktalarico]

I was getting the "illegal operation inside of a path" error in Adobe also with version 2.0.3. I tried upgrading to Adobe 8.1.1 and got a different error now: "There was an error opening this document. Access denied." I tried it with iReport 2.0.2 and 1.3.3 and still get the same error. If anyone has any suggestions, please send along. I will attach my jrxml file for reference. Thanks. [file name=arrivals_activity_TBI.jrxml size=28949]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/arrivals_activity_TBI.jrxml[/file]

[itchytoes]

Hi --

 

About 7 messages before your post (you probably missed it amidst all the other postings), Teodor said that the Adobe errors are due to a bug in 2.0.3 and will fixed in the next release. There have been a bunch of other postings about subreport issues with 2.0.3 also.

 

Betty

[ktalarico]

Actually, I did see that post from Teodor.

 

It was this post from vincewebb that led me to try upgrading to Adobe 8:

 

I have seen the same error "Illegal operation inside a path". Thrown up by Adobe 7 when viewing a pdf generated by jasperreports-2.0.3.jar. Adobe 8 displays the pdf OK.

 

As I mentioned in my earlier post, the error I get with Adobe 8 occurs on iReport versions 1.3.3 and 2.0.2, not just 2.0.3.

 

At any rate, I am fine for now using iReport 2.0.2 and Adobe 7.

 

Thanks,

K

[C-Box]

That's why we are using FoxIt Reader that is faster, smaller and doesn't create any nonsense "SpeedUpAutoStartEntries" to fasten more a "suite" that former was a programm intended just to show PDF Files.

 

Has anyone testet FoxIt-Reader with JR 2.0.3 .... (we are still using JR 2.0.2 in production)

 

regards

C-Box