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