tangi

I was using iR 3.1.3, hence I've just upgraded to iR 3.5.2 this morning, and I still reproduce the symptom, the row separator is reset to "other". Maybe you fixed it in iR 3.5.3 ?

I've decreased the severity for the workaround exists.

Thank you for your reactivity Giulio ! You gave me the workaround ! Forcing "-J-Dfile.encoding=UTF-8" in /etc/ireport.conf has solved the problem. Unfortunately you could not reproduce the bug, which is an obstacle for this bug fixing. I consider that there is still a bug, since the .jrxml file declares encoding="UTF-8" by default while its contents is NOT "UTF-8". How do you think this issue should be processed ? Should I create a new issue for this inconsistency ? Regards, Tangi

Hi Teodor, I have created the issue #4014 in the project trackers and attached the requested files generated using the JRXmlExporter. Thanks to you, Tangi

Hi, the "freeze panes" Excel functionality is available in POI, provided by the HSSFSheet. Fortunately, the JRXlsExporter's sheet attribute is protected. Hence, class JRXlsExporter can be subclassed in order to expose the "freeze panes" functionality, see the code below. I'm still searching for the way to do the same when using class JExcelApiExporter instead of class JRXlsExporter, I'll post if I found. Any idea is welcome, thanks for your attention. Tangi Code:package my.jasperreports.engine.export;import java.util.HashMap;import java.util.Map;import net.sf.jasperreports.engine.export.JRXlsExporter;/** * Natively, the JRXlsExporter does not allow to freeze panes in Excel sheets. * This class bypasses the JasperReports API and addresses directly to the POI * API to freeze panes. * @author TME */public class XlsExporter extends JRXlsExporter{ private Map panes; public XlsExporter() { super(); this.panes = new HashMap(); } /** * This overriding method is in charge of creating and freezing a pane. * @param name sheet name being created */ @Override protected void createSheet( String name ) { super.createSheet( name ); int[] pane = this.panes.get( name ); if( pane != null ) { this.sheet.createFreezePane( pane[0], pane[1] ); } } /** * Defines a pane to create and freeze in the specified sheet. * @param sheetName sheet on which the pane is to be created * @param colSplit column whose right side is split limit (0: no split) * @param rowSplit row whose bottom side is split limit (0: no split) */ public void freezePane( String sheetName, int colSplit, int rowSplit ) { this.panes.put( sheetName, new int[] { colSplit, rowSplit } ); }}

Hi, I still don't know why some generated XLS files are unreadable in Excel and some others no, but I could get round this problem by using class JExcelApiExporter instead of class JRXlsExporter. Regards, Tangi

Hi, My application exploits a CSV file (encoding: ISO-8859-1) in input and uses JasperReports to generate an XLS file. Initially I used JasperReports 3.1.3, but I upgraded to JasperReports 3.5.1 hoping that it would solve my problem, but it didn't. The first test is OK. The CSV input file is hand-made and contain few data lines (3 records). The application produces the expected XLS file which can be open by Excel 2003 and contains the expected data. Now, when the input file contains true business data, the XLS file is still generated, but not always readable by Excel 2003. The tests below show a very strange behaviour : sometimes Excel behaves as if it were meeting a problem of volume of data, sometimes as if data were corrupted or mis-encoded or I don't know what, and sometimes Excel can read the file.When trying to check if the application could produce a report containing 25000 records, the resulting report was not readable by Excel. Hence, I tried to identify a record possibly responsible for the problem. Data (Records count) => Excel --------------------------------------------- Business-originated (1000) => OK Business-originated (5000) => KO: Error at reading Business-originated (3935) => OK Business-originated (3936) => KO: Error at reading I thought : line #3936 might contain something that Excel doesn't like (although I could see nothing suspicious in the data). Hence, I have isolated that line and copied it to a new input file. Then, I repeated the test with some lines before and some lines after line #3936. Data (Records count) => Excel --------------------------------------------- Business-originated (1) => OK (unique record identical to line #3936) Business-originated (30) => OK (records from #3921 to #3950) This result shows that data of line #3936 does not prevent Excel from reading the XLS file. Consequently, it doesn't seem to be an encoding issue. I thought : if the problem is not in the data, maybe it's in the number of data, so I made a new test with new hand-made data which contain exclusively the 'a' character. Data (Records count) => Excel --------------------------------------------- Hand-made 'a'-data (1000) => OK Hand-made 'a'-data (5000) => OK Hand-made 'a'-data (50000) => OK As far as I could go, my "'a'-data" always result into a correct XLS file. This test shows not only that volume of data should not be a problem (considering my volume of business data), but also that when data only contain characters that are common to all Character Sets, then the generated XLS is OK. Consequently, it seems to be an encoding issue. As a conclusion, I don't even know how to categorize my problem, and even less find a solution. I suppose that encoding should not be a problem : when my application reads the input file, it is specified that file encoding is ISO-8859-1, hence I guess that data read are correctly converted to UTF-16 by Java, and then the XLS export library should apply a correct conversion (to which encoding?) for Excel, right ? Please help, any track is welcome ! In attachment, I provide two couples of input (CSV-formatted log) and output (generated XLS) files containing true business-originated data: the one containing 3935 records (OK), and the one containing 3936 records (KO). Regards Tangi