edikk

Hi! We are using iReport 1.3.1, but the same bug is in 2.0.2 To show this bug, you must define XML datasource to attached xml file with following XPath: /dokument/zawartosc/przesylka | /dokument/zawartosc/transportowe | /dokument/zawartosc/zbiorcze | /dokument/zawartosc/poz | /dokument/zawartosc/dokumenty Run JRViewer preview or generate PDF file. As you see (in attached PDF too) the page summary for column Przesylki->liczba is wrong. The whole summary is ok. The same problem is on our others documents. Please fix this bug or tell us how to avoid this. Regards Eduard Kustow [file name=pageSummaryError.zip size=20418]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/pageSummaryError.zip[/file]

This will work better. I forget about type convertion.

Ok, done. Is here: http://jasperforge.org/sf/go/artf2243?nav=1 Edik

Try this: response.setContentType("application/xls"); It work well for me. Edik

Try: exporter.setParameter(JExcelApiExporterParameter.IS_DETECT_CELL_TYPE, Boolean.TRUE); I think there is an error, and it work in different way Edik

Here is my solution, work well with leading zeros: Code: private void exportToXls(HttpServletResponse response, JasperPrint jasperPrint, ReportRequest reportRequest, ServletOutputStream outputStream) { JExcelApiExporter exporter = new JExcelApiExporter(); response.setContentType("application/xls"«»); exporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint); exporter.setParameter(JRExporterParameter.OUTPUT_STREAM, outputStream); exporter.setParameter(JExcelApiExporterParameter.IS_DETECT_CELL_TYPE, Boolean.TRUE); exporter.setParameter( JExcelApiExporterParameter.IS_WHITE_PAGE_BACKGROUND, Boolean.FALSE); try { exporter.exportReport(); } catch (JRException e) { communicateError(response, XLS, reportRequest, e); } } Regards Edik

I have wrote XML data source based on VTD-XML 2.0 (http://vtd-xml.sourceforge.net/ ). It is fastest for XPath'es. Example for my reports: For exporting report using default jasperreports datasource it takes more then 20 minutes to export to PDF. When I use xml datasource based on Jaxen, it takes 3 minutes. And now, when I use VTD-XML it takes some less then 1 minute. Mayby not everything can be done with VTD-XML, but for simple XPathes its enough. In attached code there is some caching mechanizm. When XPath begin with "/" so I use it like a constant value for this XML file. I introduce this, because JR rerequest fields values from every report section (not only for detail section, but for header and footer too) every time, when it moved to the next record (next() function). For big XML documents it very carry weight! Source in attachement, good luck :evil: Regards Edik [file name=WinVTDXMLDataSource.zip size=2039]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/WinVTDXMLDataSource.zip[/file] Post edited by: edikk, at: 2007/04/30 14:05

Im not sure is it help, but here is my experience... When you export date to XLS (any format), Excel may convert it in their own format, when you open the file. I had problem with export numbers which have leading zeros (I need them), and I found that IS_AUTO_DETECT_CELL_TYPE work in reverse way - true value is a false, and false is a true (I'm unsure of this bug). So if you set IS_AUTO_DETECT_CELL_TYPE to false, it will (? ;) ) auto detect cell type :) .

Maybe try to adapt iReport as an applet?

Try to run with java parameters: java -Djava.awt.headless=true ...

Thanks, Are JR team thinking about exchanging XML parser to faster?

I have print server based on JasperReports/Tomcat. Every of report have XML as datasource. Reports are very simple, no subreports, no any calculations, just filling datas from XML to JR using the one and only XPath query. Some of reports have 400 and more pages and it takes about 20 and more minutes :ohmy::sick: to generate JasperPrint object. But if I use DB datasource, so it work much faster. Do you have the same expirience with this datasources? Anybody know how to make faster filling JR from XML? thanks

I have the similar situation with w2k3, on others work fine. But I have problems with printing only when I select the printer tray. SP2 for w2k3 didnt help. Anybody found solution? thanks

I had the same problem with leading zeros. This code will help: Code: JExcelApiExporter exporter = new JExcelApiExporter(); response.setContentType("application/xls"«»); exporter.setParameter(JRExporterParameter.JASPER_PRINT, jasperPrint); exporter.setParameter(JRExporterParameter.OUTPUT_STREAM, outputStream); exporter.setParameter(JExcelApiExporterParameter.IS_DETECT_CELL_TYPE, Boolean.TRUE); exporter.setParameter( JExcelApiExporterParameter.IS_WHITE_PAGE_BACKGROUND, Boolean.FALSE); try { exporter.exportReport(); } catch (JRException e) { communicateError(response, XLS, reportRequest, e); }

I had the same problem with barcodes in Excel. The only solution wich i found is to rewrite JExcelApiExporter class (attached) [file name=jexcelapi.zip size=9171]http://www.jasperforge.org/components/com_joomlaboard/uploaded/files/jexcelapi.zip[/file] Post edited by: edikk, at: 2007/03/22 09:28

Generate every document separately and than join them using iText

I had a few problems with JasperReports on Sun JVM. Much of them are disappear when change to BEA JRockit. Try, maybe it help you too.

I using JasperReports/iReports 1.3.1 (on the previous was the same problem) to print documents on a different printer tray depending on the size - A6 and A4. Everything work fine but Windows 2003. When I using this mechanism on Windows 2003 the image of document A4 is moved about 2 cm on paper from one side and cutted on another side. When I send print to the default printer tray documents are printed fine. Its independend of JVM - Sun and JRockit work the same. Its independent of printer - Samsung, HP, virtual generate the same problem. On XP everithing work fine, so its maybe something on 2003. The problematic image files are yet on Windows SPL files (C:Windowssystem32spool...etc) Windows 2003 SP RC didnt help. Are anyone had the same problem and know the solution? Any ideas? Regards Eduard Kustow