Jump to content
We've recently updated our Privacy Statement, available here ×

gueugaie

Members
  • Posts

    5
  • Joined

  • Last visited

 Content Type 

Profiles

Forum

Events

Featured Visualizations

Knowledge Base

Documentation (PDF Downloads)

Blog

Documentation (Test Area)

Documentation

Dr. Jaspersoft Webinar Series

Downloads

Everything posted by gueugaie

  1. 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.
  2. 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.
  3. 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
  4. 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
  5. Hello all. I've been encountering an issue where numbers from a field overflow the box in which they should be. Not that the field stretches, but the text just prints itself starting inside the field, and finishing outside. I attached a picture to show you. Now for the specifics of the issue. My text fields use the pattern attribute to format Doubles. As currency values, I want the formatted numbers to right-align themselves in their field. Trouble is : when the formatting requires a thousands separator, the text starts overflowing on the right. If one separator is needed, then one characater is printed outside the field. If two separators are needed, then two caracters are printed out. And so on. If no separator is needed, then the text aligns itself as expected. If that matters, this does not happen on left align, and the right overflowing happens wether I use a custom pattern, a currency pattern, even if I use a Java instruction as the field expression to format my number. From what I saw, the issue is specific to the white space being the thousands separator (FR locale), as it does not occur when , is used. The issue is also not font-dependant, as it happens with times, courrier and others. I used Adobe Acrobate as a reader, on Mac and PC, as well as OSX's Preview.app and it makes no difference, so I really think it's not so much a pdf- but rather a Jasper (maybe iText ?) issue. I'm a bit lost... And without a clue about how to proceed... Any help ? size=200]http://www.jasperforge.org/components/com_joomlaboard/uploaded/images/align.JPG UPDATE : See possible solution here : http://www.jasperforge.org/index.php?option=com_joomlaboard&Itemid=215&func=view&catid=8&id=17595#17595 Post edited by: gueugaie, at: 2006/11/06 14:09 Post edited by: gueugaie, at: 2006/11/06 14:34 Post edited by: gueugaie, at: 2006/11/06 14:46 Post edited by: gueugaie, at: 2006/11/06 21:08
×
×
  • Create New...