jgaughan

I work on an application with many Jasper reports: at least 50. We have a bug with reports that have JFreeChart charts on them where the report displays fine on screen, but when printed, part of the report is missing or in the correct location. For example, a report might have two pages. The first page shows a summary of several transactions, and the second page shows bar and pie charts for aggregates of various transaction properties. Everything is fine on screen, but when printed, I can see a visible line approximately 80% of the way to the right margin where to the right, everything is fine. To the left, everything on the page is either missing, or is shifted down an inch (missing in the QA lab, shifted in dev running in Eclipse). This shift only occurs on pages that have charts. I am not sure if this is a bug in JasperReports, JFreeChart, or even JCommon, but I see nothing logged through Log4j, nothing in stdout/stderr, and no exception being thrown or caught when this occurs. Versions: JasperReports 3.5.2 JFreeChart 1.0.12 JCommon 1.0.15

It may not be applicable to those specific versions, but the team I am on at work uses JasperReports 3.5.2. On some projects, we use that to run reports compiled with 2.0.5. My experience is that JasperReports is very good with backwards compatibility. Ideally this would be a moot point, but sometimes you just can't upgrade jar files willy nilly. The risk of breaking production code is too great. However, the only real issues I had was upgrading past the 3.5 barrier which introduced some redesigns and refactorings, and adjusting our custom build process to work with it. But the reports ran fine, and now everything just works.

I changed the PDF encoding from UTF-8 to ISO-8859-1 and the problem went away. This is not an ideal solution for true i18n, but for software being deployed only in the U.S. for the "en_US" and "es_MX" locales, it will work. Post Edited by jgaughan at 09/10/2010 18:15

Try making sure you don't have different versions of the same library in your classpath (check Tomcat too). I would check out iText as well as JasperReports, but really, any library is a candidate. Java class loading/locating can be bizzarre sometimes.

You get what you pay for. This is open source software, and you don't have to pay for it. If you want better support, pay for the professional edition that comes with a support contract. Until then, rely on the community. People may or may not have answers for your questions, and the project maintainers may or may not have the time to give free advice. Either way, you are (possibly) getting free support from the goodwill of others. Or you are paying for it. Your choice.

If you can precalculate the beans ahead of time, just put them in the report as a parameter, and pass that into the subreport's data source: <dataSourceExpression>$P{SubreportParameter}</dataSourceExpression> If the subreport's data source relies on properties of the parent reports current record, you can try calling out to a helper: <dataSourceExpression>$P{HELPER}.getSubreportDataSource($F{FieldName})</dataSourceExpression>

I have an issue where non-ASCII characters (e.g. accented characters) do not display correctly when exporting to PDF. JasperReports is integrated into an application created by my company. In this specific instance, we load a report and fill it multiple times for multiple targets: printer, database (serialized XML), and exported to PDF. The report fills correctly all three times. Text is translated from a database table using an internal framework, and is placed in the report as a string correctly. I can inspect the data in the debugger and see it is correct. The print version displays correctly. The database version does as well, if I load it and print it. The PDF exported version has boxes where the characters are that take more than 7 bits. If I export to XML, the data is correct. It looks like the problem is either the encoding of the PDF, the code page used, or the font embedded. The report uses Lucida Sans Typewriter. The font works fine in the other reports, and even in Word or other applications. Is there a property I need to add to the parameter map passed in to the exporter? The application is using JasperReports 3.5.2 and iText 2.1.6. Post Edited by jgaughan at 08/24/2010 19:37

I have the same problem as the OP, and can provide more information that may help. The program flow works like this: 1. Load the report. 2. Create beans to hold all the data, in a JRBeanCollectionDataSource. 3. Perform application-specific logic to determine how many copies are required. For example, one copy may be printed, another serialized to a database table, and another exported to PDF. 4. Fill each copy of the report individually. Each report will be slightly different, with minor changes to some of the static text. Some copies may have a locale override as well, translating the entire copy of the report into a separate language with different locale settings (e.g. period or comma for decimal separator). Up until this point everything works fine. I can debug and inspect beans and variables and see that translated text is correct. At this point in the process, I have no reason to believe there are any problems. 5. Print, save, and export each JasperPrint as appropriate. At this point, the versions printed and serialized to the database are correct (if I deserialize the DB version and print it, it shows up correctly). The PDF version has squares where non-ASCII characters are. In this case, the missing characters are accented characters in the es_MX locale (Mexican Spanish). The font used is Lucida Sans Typewriter, which definitely contains those characters. Most fonts do, since those aren't even Unicode, they are just 8 bit characters used by most Western fonts/code pages. I thought maybe this had to do with font embedding, but even if the font is not embedded or only has a character subset, it should display correctly on the same machine used to generate the PDF (in this case, my dev system which certainly has the correct fonts installed). Maybe I need to specify more parameters to the export process? I noticed that CHARACTER_ENCODING is not used by the PDF engine, but TAG_LANGUAGE is. I looked at the JavaDoc and I am not sure what the contents should be (locale? code page (but Java uses UTF-16 anyway)? literal name of the language?) or if this is even used for anything besides populating something in the "properties" box in Adobe Reader.

You print to fiscal printers the same as any other printer. The only issue would be if the printer needs to mark a specific part of the document, you will need to experiment to get it to line up correctly. This varies between countries with different legal requirements.

That worked, thank you. Reports now compile both in my workspace and on our build server and everything just works. I am very impressed with the ease of upgrading from 2.0.5 to 3.5.1 given the large number of changes and fixes. The only issues I have encountered are related to our antiquated Ant scripts, so far the actual Java side of things has run flawlessly. You guys have done a good job not breaking things (can't say that much for the maintainers of Castor) as well as adding value to the new versions.

My company integrates JasperReports into another Java product, and we use Ant to build our software. I recently upgraded from JasperReports 2.0.5 to 3.5.1: as well I also instructed the development team to use iReport 3.5.1, and I updated all of our JRXML files by loading and saving in iReport 3.5.1 to use the new format. Everything works great when building locally in Eclipse and running the application. Our build server fails miserably. It cannot compile any reports. I looked at the system properties, classpath, etc. and tracked it down to something with Ant. I understand that this is the JasperReports forum, but I am hoping that someone has seen this issue before because I am quite puzzled. When I compile reports on our build server (also locally) using Ant 1.7.1, I get the following exception chain: net.sf.jasperreports.engine.JRRuntimeException: Error creating SAX parser at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.createParser(JRReportSaxParserFactory.java:113) at net.sf.jasperreports.engine.xml.JRXmlDigesterFactory.createParser(JRXmlDigesterFactory.java:1310) ......(snipped for brevity)........ Caused by: org.xml.sax.SAXNotSupportedException: Property 'http://java.sun.com/xml/jaxp/properties/schemaLanguage' must be set before setting property 'http://java.sun.com/xml/jaxp/properties/schemaSource'. at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.setProperty(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.setProperty(Unknown Source) at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.configureParser(JRReportSaxParserFactory.java:146) at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.createParser(JRReportSaxParserFactory.java:108) ... 38 more Looking in the source code for both JasperReports and xerces, I can see exactly where xerces is throwing the exception and it appears to be valid. However, from the JasperReports source code: parser.setProperty("http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema"); parser.setProperty("http://java.sun.com/xml/jaxp/properties/schemaSource", schemaLocations.toArray(new String[schemaLocations.size()])); I cannot understand how these properties are being set in the wrong order, when according to the source code that is simply not true. They are clearly being set correctly The weird thing is that when I compile using the version of Ant supplied with Eclipse 3.4.2 (Ant version 1.7.0), the problem goes away. If I use the official Ant 1.7.0 or 1.7.1, I get this error. All I can think of is that there is some strange classpath or version issue going on, but tracing the class versions at the JVM level is giving bogus information. It says pretty much every class not in the JRE came from ant.jar, so my guess is Ant is using a custom classloader that is corrupting this data. Has anyone seen this problem or anything like it? Does anyone have any ideas? I already looked through the documentation and googled, but pretty much every common issue is related to getting the JRC task to work in the first place. JRC is running, it successfully loads the SAX parser, but the SAX parser appears to be unhappy. Code:net.sf.jasperreports.engine.JRRuntimeException: Error creating SAX parser at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:116) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.Main.runBuild(Main.java:758) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)Caused by: net.sf.jasperreports.engine.JRRuntimeException: Error creating SAX parser at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.createParser(JRReportSaxParserFactory.java:113) at net.sf.jasperreports.engine.xml.JRXmlDigesterFactory.createParser(JRXmlDigesterFactory.java:1310) at net.sf.jasperreports.engine.xml.JRXmlDigesterFactory.createDigester(JRXmlDigesterFactory.java:1285) at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:203) at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:168) at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:152) at net.sf.jasperreports.engine.JasperCompileManager.compileReportToFile(JasperCompileManager.java:115) at net.sf.jasperreports.ant.JRAntCompileTask.compile(JRAntCompileTask.java:413) at net.sf.jasperreports.ant.JRAntCompileTask.execute(JRAntCompileTask.java:259) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) ... 25 moreCaused by: org.xml.sax.SAXNotSupportedException: Property 'http://java.sun.com/xml/jaxp/properties/schemaLanguage' must be set before setting property 'http://java.sun.com/xml/jaxp/properties/schemaSource'. at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.setProperty(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.setProperty(Unknown Source) at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.configureParser(JRReportSaxParserFactory.java:146) at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.createParser(JRReportSaxParserFactory.java:108) ... 38 more--- Nested Exception ---net.sf.jasperreports.engine.JRRuntimeException: Error creating SAX parser at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.createParser(JRReportSaxParserFactory.java:113) at net.sf.jasperreports.engine.xml.JRXmlDigesterFactory.createParser(JRXmlDigesterFactory.java:1310) at net.sf.jasperreports.engine.xml.JRXmlDigesterFactory.createDigester(JRXmlDigesterFactory.java:1285) at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:203) at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:168) at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:152) at net.sf.jasperreports.engine.JasperCompileManager.compileReportToFile(JasperCompileManager.java:115) at net.sf.jasperreports.ant.JRAntCompileTask.compile(JRAntCompileTask.java:413) at net.sf.jasperreports.ant.JRAntCompileTask.execute(JRAntCompileTask.java:259) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:416) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.Main.runBuild(Main.java:758) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)Caused by: org.xml.sax.SAXNotSupportedException: Property 'http://java.sun.com/xml/jaxp/properties/schemaLanguage' must be set before setting property 'http://java.sun.com/xml/jaxp/properties/schemaSource'. at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.setProperty(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.setProperty(Unknown Source) at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.configureParser(JRReportSaxParserFactory.java:146) at net.sf.jasperreports.engine.xml.JRReportSaxParserFactory.createParser(JRReportSaxParserFactory.java:108) ... 38 more

Recently I upgraded a project from JasperReports 2.0 to 3.5.1. This involved both upgrading the core JasperReports jar files, as well as instructing all development team members to use the new version of iReport. The upgrade went smoothly overall, but there is one minor issue. When I save reports using iReport 3.5.1, the reports do not compile. The language is unknown. When I add a "language" attribute to the root "jasperReport" tag and set it to "java" everything works. The odd thing is, the language is set correctly when I view the report in iReport. Is there some other setting I am missing? Is there a master system property I can set? Otherwise, we need to open up the JRXML file and add that XML attribute each time we save and before compiling.