Problem with right alignment

[tnodev]

Hello,

 

I have a textField which contains a BigDecimal with a Rigth alignment and a currency pattern : #,##0.00# € in a classic band detail.

 

But my column is not well aligned, there is a shift between large value (123 456.12 €) and small one (0.00 €)

 

please help, thanks

 

See the file (it's a french one... :blink: )

[file name=Article1232.pdf size=2475]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/Article1232.pdf[/file]

[lucianc]

Can you post a (simplified) JRXML design that can be used to reproduce this? What JR version are you using? Does this happen for PDF only or other formats as well (JRViewer, HTML, etc)?

 

Regards,

Lucian

[tnodev]

I'm using Jasper 1.2.7, and i'm using PDF format only.

here the jrxml file [file name=article123_2.jrxml size=11113]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/article123_2.jrxml[/file]

[lucianc]

I haven't been able to replicate the behaviour. I ask you again: does this occur in JRViewer as well? (I understand that you only use PDF, but you could try to preview the report using JasperViewer for diagnosis purposes..)

 

One thing to check: you are using text fields with pdfFontName="Helvetica" and no fontName attribute. A basic contract of the JR rendering engine is that the AWT font used during report fill matches the PDF font used for exporting (the fonts should produce the same metrics). If this assumption does not hold, PDF text rendering might be affected. In your case, the default AWT font should match the Helvetica font.

 

Regards,

Lucian

[tnodev]

It's fine with JRviewer :S ...

 

So I have a problem with the Font, I'm looking for it...

 

Thanks

[gueugaie]

I've had the same problem with my export to PDF using french locale and the white space as the thousands separator.

See my post here :

http://www.jasperforge.org/index.php?option=com_joomlaboard&Itemid=&func=view&catid=8&id=17573#17573

There is a picture included.

As a mean of reproducing the bug, take any UTF8 aware system (Linux, MacOS, Win XP), set your Java locale to Locale.FRENCH (in Java : Locale.setLocale(Locale.FRENCH ) and right align numbers with a formatter that involves thousands separator.

The issue presents itself, as far as I can tell, everytime, on PDF exports.

 

After comparison with other outputs (html, xml) and after playing with the Java DecimalFormat options, I narrowed it to a PDF generation issue relative to the whitespace character, which is the french separator for thousands.

Carrefull comparison of the PDF rendering using different PDF readers on various platefomrs and OSes rulled out the possibility of a reader malfunction. Exporting different PDFs, with different fonts without or with embedding ruled out a font issue too.

 

As the only way to reproduce the behavior was with the DecimalFormatter, I decided I'd do some more testing. So instead I created a method that would be in charge of doing the number formatting and output a string directly, insteand of formatting during the report.

That way, I could play with the string and carrefuly study the behavior of the alignment. Those tests showed me that only the space created by DecimalFormat was provocing the progressive mis-alignement, whereas spaces that I would append myself weren't changing a thing.

 

As an act of desperation, I decided to study my string byte by byte, and there was the revelation.

As specified in the Java API, when the DecimalFormat is used in the french local, the thousands separator is not a regular space, but a non breaking space. In Latin1 URL encoding, %a0 and not %20. Or, as Java uses UTF8, the formatter that Jasper calls produces a two byte special character, the non breaking space, encoded which notation is "backslash"u00a0 (or %2C%a0 in URLEncoding, or again "ampersand"nbsp; as an HTML entity).

 

That much is sure.

As it seems that Jasper uses cp1252 (that is Windows Latin 1) encoding when embedding fonts into PDFs, the two byte value of the formatter gets misinterpreted, and I guess that the alignment calculation gets wrong each time a non breaking space in inserted.

So for a number in the thousands, 1 space is created but miscalculated. At 1 million, it's two spaces, and so on.

 

As far as I am concerned, this looks like a bug in JasperReports, as I haven't seen any doc on that particular issue.

I'm not familiar with the bug tracking software, but I'd appreciate someone informing either me if this is a known issue with a better workarounf, of the Japser developers if indeed this is a yet undiscovered bug.

 

 

WORKAROUND :

call the decimal formatter yourself, instead of using JasperReports pattern attribute.

My values now get inserted in my report like this :

Code:

(new DecimalFormat("#,##0.00"«»)).format($F{value}).replace("u00A0"," "«»)

Post edited by: gueugaie, at: 2006/11/06 21:12

[lucianc]

We were not able to replicate this. I've attached a package containing the report we used and the PDF output.

 

Could you post a simple static report that shows this behaviour, along with the generated result? Also, specify the JR/iText versions you are using.

 

Regards,

Lucian [file name=nf.zip size=2379]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/nf.zip[/file]

[gueugaie]

Hi Lucian.

 

Thanks for your interest.

I confirm you PDFs look fine, so our readers should not be in question, I guess.

 

As for me, I have created the simplest Eclipse Java Project that maybe will help you find out what's wrong. As simple as can be. Just one field in the report.

 

In this project :

- A dummy POJO Object called SimpleObject, that has a Double called value.

- The JasperTest method, first creates a JasperDataSource from an ArrayList of SimpleObjects.

- Run the CompileManager, outputs a PDF, boom.

 

The result is in sampleReport in PDF.

 

The Eclipse Project datas can show you what versions of various JARs I am using, but for simplicity's sake (I batch copied another forlder's lib):

lib/commons-beanutils.jar

lib/commons-beanutils-1.7.0.jar

lib/commons-chain-1.1.jar

lib/commons-collections-3.2.jar

lib/commons-digester-1.7.jar

lib/commons-fileupload-1.1.1.jar

lib/commons-io-1.1.jar

lib/commons-javaflow-20060411.jar

lib/commons-lang.jar

lib/commons-logging-1.1.jar

lib/commons-logging-api-1.1.jar

lib/commons-validator-1.3.0.jar

lib/itext-1.4.6.jar

lib/jasperreports-1.2.7.jar

lib/jfreechart-1.0.2-demo.jar

lib/jxl.jar

lib/poi-2.5.1-final-20040804.jar

 

This must have somthing to do with Locale settings, so I'd suggest you try setting your own to French.

 

Thanks for any pointers on what I'm doing wrong or what is goign wrong.

 

g. [file name=jasperTest.zip size=5129]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/jasperTest.zip%5B/file]

 

 

...

 

So I took your own .jrxml file, ran it through

Code:

and it gave me the picture I join to the message

size=297]http://www.jasperforge.org/components/com_joomlaboard/uploaded/images/jasper.JPG

Post edited by: gueugaie, at: 2006/11/10 14:50

[gueugaie]

As you might have guessed from the previous post, I mostly use JasperReport through JavaCode.

 

I ran your test jrxml on iReport for testing, and it turned out OK.

So, well, the way I create (or compile) the jrxml report in my Java Code produces a different output than iReport does.

[lucianc]

Ok, managed to replicate it using iText 1.4.6. I was using 1.3.1, and the issue doesn't occur on this version.

 

Until we investigate this and decide whether it's an iText/JR bug or something is wrong with the report fonts, you can use an older iText version (or use your workaround).

 

Regards,

Lucian

[gueugaie]

Thanks once more for your interest.

 

Actually, I think sticking with iText 1.3.1 is a more interesting solution, as hopefully, they won't be needed when the issue gets identified.

 

I also confirm that iText 1.3.1 solves the problem for my various uses of JasperReports.

So thanks again for your time.

G.

[thushfit]

Please answer for this queustion 

http://stackoverflow.com/questions/30072575/jasper-report-alignment-not-setting-properly-when-printing-more-than-one-report/30075094?noredirect=1#comment48299697_30075094