[#4555] - Alignment of line and rectangle with 0.5 pix width

Feature request
Project: Severity:
Component: Reproducibility:
Assigned to:

We have a problem with the lines in the jasperreport when they are smaller than 1 pix (0.5 as on the picture). You can see the alignment of the static text with the 0.5 border and the rectangle with the 0.5 thickness are the same, the line holding together with the rectangle is positioned on the same pixel as the both (rectangle,static text) but the line is aligned right in that exact pixel, the box and its border is alligned left in the also same pixel. Either iReport nor jasperReports is not giving an option for the line alignment (left, center, right) or something similar. What do you suggest?

We currently are using an old version of jasperReports 0.6.1. to be exact - if i draw a line in the old designer the code looks like this :

<line direction="TopDown">














<graphicElement stretchType="RelativeToBandHeight" pen="Thin" fill="Solid" />


In the 3.7.0. the pen type Thin dissapears and you offer 0.25,0.5,1…pixel width of the line.


<reportElement stretchType="RelativeToBandHeight" mode="Opaque" x="0" y="1" width="1" height="11" forecolor="#000000" backcolor="#FFFFFF"/>

<graphicElement fill="Solid">

<pen lineWidth="0.5" lineStyle="Solid"/>



If i open an old report made with the 0.6.1. version the lines are not anymore aligned or in other words, the Thin is converted in the 3.7.0 version to 0.5 pix, which is right, just the alignment of the lines isn't anymore. I assume in the old version you had a centered alignment for the lines and in the 3.7.0 version you allign the rectangles and graphical elements left in the pixel, the lines are alligned right?This happens only if the line width is not a whole number, thin lines are very useful and 1 pix line width is very strong.

What is the solution for our problem?

Binary Data --report2.jrxml2.19 KB
crominium's picture
Joined: Feb 18 2008 - 10:26pm
Last seen: 7 years 5 months ago




In JR 2.0.3, we have changed the way borders are drawn, when we introduced new types of borders and when we allowed borders to have any width.

If you have reports older than 2.0.3 and you want them to work like they did, then you need to turn this config property to true:


Note that this property can be set globally (for all reports) in the jasperreports.properties file, or can be set to individual reports as a custom report property. I suggest you set it at report level for all your old reports, and for new reports, you just use the new types of borders.

Setting this property for all your old reports in an automatic way can be achieved with an Ant update task that was introduced in JR 3.7.1 (earlier this week).

If you get JR 3.7.1, check the /demo/samples/antupdate sample provided.


In the build.xml file of this sample, notice the commented line which specifies the legacy border setting updater. Uncomment that line if you want your JRXMLs to have the property added automatically when updated to the new JRXML syntax.

I hope this helps.


Setting this property has no effect on 0.5 pix line widths. If you draw two lines at 90 degrees to each other with 0.5 width. Preview the lines and zoom in. They don't form a crisp corner.



When you say zoom in, what are you referring to exactly?
Do you zoom into the iReport's design page?
Or do you zoom into a generated report (preview page).

I'm asking because the borders you see off might be drawn by iReport and would not necessarily be the way JR draws the borders.

I suggest we put aside iReport for a moment.

What version of JasperReports are we talking about? Can you post here a JRXML with the problem?
For correct design preview, you should use the JasperDesignViewer, which is part of the JR JAR. You can see how all the JR samples let you preview them using the ant viewDesignXML task from command line.
Use it for your file and let me know if the problem is with JR or iR.

Thank you,



Using JR 3.7.1. Same problem persists in Ireports view for design, preview and pdf preview and ant task viewDesignXML.

Attached file shows problem - square on left is perfect using the rectangle. Sqaure on right has crossed corners created using lines (you may need to zoom in to see).



The way borders and lines has changed in JR 2.0.3, with the introduction of new types of lines.
At the time, thought a lot about how lines should be drawn and the current behavior is what came out with.

We thought that having the thin lines like this cross at corners is an acceptable side effect.
This is because many times people concatenate lines and if we would draw them any different, there would be gaps where the lines were supposed to meet.
Basically you could not put several lines together to make a bigger one, because you would see small gaps. You would then have to make those lines overlap at least 1 pixel so that the gaps disappear, but overlapping elements do not work well with grid exporters and so on.

So what I'm saying is that the current behavior is what we intended and I don't think we would want this to be revisited. I order to solve problems such as the one you mentioned, we would have to let the user configure the types of line caps and other details such as these. But this would be more like a request for enhancement.

Thank you,



Anything new on this one?

Thank you,


Looks like it needs to be added as a request for enhancement. At present the way it works is not giving the professional image I expected to a number of reports which in my previous version were perfect.


We can transform this into a feature request.
But since you mentioned the reports were perfect in the old version, why don't you use the above mentioned net.sf.jasperreports.export.legacy.border.offset config property, so that they continue to look the same?

Thank you,


I tried that originally but it didn't work, all the lines overlapped so crosses appeared at the intersection. Since then I have had to create more reports using barcodes which didn't give me everything I wanted in the older version, but the new version did. If you could transform this into a feature request that would be be brilliant.