jasper_reports NG
Right after the release of the first release candidate of Koo, we've committed a bunch of exciting changes in the jasper_reports module. Those changes can be classified in two separate areas: performance and localization.
Performance
In the performance area, we've created a Java process, started automatically when the first report is executed, that avoids the overhead of starting the Java Virtual Machine each time a report has to be printed. The other performance improvement affects only reports using the XML interface, which can benefit from up to a 10% speed increase thanks to the use of CSV files instead of XML. It is fully compatible and does not change anything when users create new reports.
Localization
It is now possible to use translatable fields, such as product names and country names, in any language. By default, the XML interface creates translatable fields in the language of the user executing the report. If the field is assigned the java.lang.Object type instead of java.lang.String in iReport, the report can use:
$F{product_name}.get( "ca_ES" )
If the report is an invoice, for example, it has a relation to the party. In that case, you can use:
$F{product_name}.get( $F{partner_language} )
If a translation is not available for that language, the default translation is used.
We also decided to extend JasperReports' localization features. The report designer can translate text with:
tr("This is the text I want to translate")
or with parameters:
tr("{0} out of {1} think this translation system is great!", $F{positive},$F{total})
Plural forms are also supported:
trn("One person", "{0} people", $F{people})
Almost all functions in java gettext have been implemented, including versions with configurable locales. For example:
tr( new Locale("ca", "ES"), "This text will be translated into Catalan even if the default report locale is in german!")
The jasper_reports/java directory contains two scripts for extracting these texts:
jrxml2pot: extracts report texts into a.potfile.po2properties: converts a translated PO file into a.propertiesfile.
The report directory should contain:
text
superreport.jrxml
superreport_ca_ES.properties
superreport_de_DE.properties
...
If a translation is unavailable, the original text is printed.
This mechanism can be integrated into modules and translated through Launchpad. Because JasperReports lacks infrastructure for this kind of task, we had to reimplement the GroovyCompiler, creating I18nGroovyCompiler. This means that:
- Groovy must be used as the report language.
- Reports cannot be previewed inside iReport.
Update: Recent tests have shown that some reports take less than half the time they took with the XML backend, so performance gains are significant depending on the report.
