mbarnard

Thanks Lucian, This works, mostly. It's a little confusing. Sometimes "break" means page break, and sometimes it means tab break... It would be good if property names would distiinguish. The "break.after.row" property doesn't work when applied to the subreport element itself. I had to put it on a dummy textfield in a dummy band between my two subreport elements. If I put it on a textfield element below the subreport element in the same band, it caused the break to occur before the subreport for some reason. A bigger problem is that the "break.after.row" property prevents tab names from working when set using the net.sf.jasperreports.export.xls.sheet.names property, set at the report level. I've tried one property followed by a list of tab names (Detail/Summary/Communities), as well as individual properties (...sheet.names.1, ...sheet.names.2, etc). Instead of the three tab names "Detail", :"Summary", and "Communities" I get "Detail", "Detail 2" and "Detail 3". Tab names do work when using page breaks to get tab breaks. We are currently using JasperReports 3.5; perhaps this was fixed in a later version.

I was able to improve the Excel row height problem (but not completely fix it) by making a small change in the JExcelApiExporter, and recompiling the jar. This is JasperReports 3.5.3. In the code below I changed the multiplier from 20 to 30. It seems as though this provides an initial row height value, which Excel will later increase if the cell has a lot of content, but Excel often gets the calculation wrong. But it is strange because Excel doesn't make a mistake on the files it generates, so I think there is something strange about the way JExcel generates xls files. protected void setRowHeight(int y, int lastRowHeight) throws JRException { try { // sheet.setRowView(y, (lastRowHeight * 20)); // twips sheet.setRowView(y, (lastRowHeight * 30)); // twips } catch (RowsExceededException e) { throw new JRException("Error generating XLS report : " + jasperPrint.getName(), e); } }

Thanks for your reply Lucian. I have a simple test report with three subreports that should generate three Excel tabs (using the net.sf.jasperreports.export.xls.one.page.per.sheet property) which I've been using for testing. If I set Ignore Pagination to true in the master report and the subreports, then if I use Break elements in the master report I get 3 tabs in Excel, and 3 pages in the PDF. If I use the break.after.row property on the last element of each subreport, then I get 3 tabs in the Excel but only 1 page in the PDF, because break.after.row only applies to the Excel exporter. If I set Ignore Pagination to false in the master report and the subreports, then if I use either Break elements or the break.after.row property, I get many Excel tabs (one for each page due to normal pagination, plus empty tabs due to the Break elements or the break.after.row properties), but the PDF has normal pagination. This is just what I'd expect, but I want just one Excel tab for each subreport, but many pages in the PDF. The problem is that Excel tabs (worksheets) are coupled to pages, even though they are logically different things (I think!) It would be much better if we could fill the report with normal pagination, and then have a property like xls.new.sheet.after.row to control tabs independently in the Excel exporter. I'll look into logging this as a possible enhancement in the JR tracker.

I have a report which uses subreports and Break elements between them so that each subreport will show up on a separate Excel tab, and this works fine. The problem comes when the report is exported to PDF. In this case the report will have one PDF page for each tab, and the length of the last page seems to be determining the length of all the pages. If the last page has the most data, everything is fine, but if the last page is short, all the other pages are truncated, even in the middle of detail rows. Is this just the way the PDF exporter works? Can PDF pages be different lengths? Can we tell the exporter to use the longest page as the length for all pages?

On JasperServer, in WEB-INF/classes/jasperreports.properties, do you have: # report exporter hints override export parameters net.sf.jasperreports.export.parameters.override.report.hints=false The "report exporter hints" are the properties you set in the report. You want "false" so these report properties aren't overridden. You'll find the export parameters (parameters to the exporter classes) defined in WEB-INF/applicationContext.xml

Found out the answer myself: just set a property in the JRXML whose name starts with net.sf.jasperreports.export.xls.sheet.names. jasperforge.org/uploads/publish/jasperreportswebsite/trunk/config.reference.html#net.sf.jasperreports.export.xls.sheet.names.{arbitrary_name}

Is there a way to control the worksheet names in an Excel report that is run and exported in JasperServer? I know that if I export the report to Excel using the Java API I can use the SHEET_NAMES exporter parameter to set the sheet names. But is it possible to do this with a report that is run in JasperServer? The particular report I'm thinking of has 9 subreports, each one on a separate Excel sheet (tab) and the names would be like "Inquiry Date", "Lead Status", etc. I've thought about modifying JExcelApiExporter to see if I can pull the names from report properties in the report definition. Does this seem possible? If I do it would anyone be interested in the solution?

Yes it is possible. In iReport set the report property net.sf.jasperreports.export.xls.one.page.per.sheet to true. Then the problem is how to make sure that page breaks occur only where you want to start a new worksheet. What I have done is create a subreport for each worksheet. These subreports have the Ignore pagination property checked. The master report also has Ignore pagination checked. Each subreport goes in its own group header and I put a Page Break element after each subreport element. Then each subreport ends up appearing in its own Excel sheet.

I got the JS source code from the JasperForge SVN repository (/trunk) and it looks like there was (on 12/15/2009) an error in the scripts/mysql/js.jdbc-mysql.properties file: metadata.jdbc.url=jdbc:mysql://localhost:3306/jasperserver?useUnicode=true&characterEncoding=UTF-8 The & before "characterEncoding" should be XML encoded to & In the normal Tomcat + MySQL build this string goes in META-INF/context.xml, and the XML parsing error keeps Tomcat from starting the app: SEVERE: Parse Fatal Error at line 31 column 88: The reference to entity "characterEncoding" must end with the ';' delimiter. Has anyone else run into this problem? Maybe it's already been fixed in SVN. Anyway, here's the part I really don't understand. I had JS 3.7 RC running fine from the packaged (.exe) installer. I removed the /jasperserver folder from /webapps (saving a copy elsewhere) and laid the new jasperserver.war file (from the SVN source) in webapps. Then I fired up Tomcat and got the error indicated above. Since this is Tomcat 5.5 and the app was being deployed from a war file, Tomcat copied META-INF/context.xml to its conf/Catalina/localhost/jasperserver.xml. I can get the app to run by manually editing this file, changing & to &. Now here's the really strange part. If I shut down Tomcat, delete the bad webapps/jasperserver folder, copy back the good jasperserver app from where I saved it before, delete the conf/Catalina/localhost/jasperserver.xml file, delete everything in the Tomcat work/ folder, and start Tomcat up again... the old conf/Catalina/localhost/jasperserver.xml is back, and causes the same XML parse error. I have no idea where this file is coming from. I did a search through the (good) webapp and it is not there, the META-INF/context.xml file is fine, etc. Any Tomcat experts out there who can explain what is happening here??

Teodor, Thanks for the quick response. I'm just learning JasperReports, but so far I like it a lot. I think my issue must be encountered by many new users. It has to do with the designed behavior of the bands and, if you are using iReport as I was, what iReport leads you to expect. One expects the following band order, corresponding with the way the default bands are laid out in iReport: ... detail, column footer, page footer, summary. If you just go with the iReport defaults, but don't put anything in the summary, you won't even realize that it is the summary band that is messing things up. But those are issues for iReport. As far as JasperReports goes, I really think the default band order should be the order given above. That is, the column footer always follows the last detail (or group footer) so that it can contain things like column totals, and provide a visual close for the column. Page footer and summary come later. Then the main configuration parameter is whether you want the summary above the page footer on the last page, or on a final page by itself. Just my two cents!! Anyway, thanks for a very good and useful product.

I'm using iReport to make a small one-column report (about half a page) in which I want the column footer to print immediately below the last detail band. I have a group header, and the group footer size is set to 0. I set isFloatColumnFooter="true", but I found that the summary band is printing between the last detail band and the column footer, so to fix it I need to set the summary band height to 0. Is this a bug or a feature? It took quite a bit of trial and error to track down. The Ultimate Guide just says that in some cases (unspecified) the column footer can follow the summary. It does seem counter-intuitive!