mattbates

From trial and error I've found that tf you set markup on a textfield to html. You can get a few basic things like bold, italic, unordered and ordered lists, and breaks. I am very keen to use it for conditional font formatting, and embedded tables as well but can't get anythign else to work. The actual html component you see in the pallette has been abandoned I think. It certainly doesn't render nealry as nicely as the markup attribute.

That does indeed help Teodor. Thank you very much. This all seems very confusing though. I certainly don't understand why the relationship between stretch and position type would work in this way. And it seems to me that Jasper is not honouring the stretchType field on Sub Reports if it is indeed impossible to not have your sub report stretch. Can you actually achieve anything useful by setting the stretchType of a Sub Report? Should iReport be defaulting Sub Reports to that stretchType?

You could use StringUtils.join in an Expression to turn a List into a String (or StringUtils.split for the opposite). But I can't see a good way to get this into your SQL. You might try using a dummy report just to change the list your users select into a String and pass it as a parameter into your real report embedded as a subreport.

mmulligan03 wrote: If you are doing it through web services... if you are running it through the web... Nope I'm not doing either, my users are going to use the JasperServer UI. But that URL looks very useful.

ramnik Wrote: 1. add parameter to the report 2. provide default value to the parameter Unfortunately the point is there are two different values, not one.

reports2.zip uploaded with relative subreport paths.

I would quite like to expose one report definition on Jasper Server as two different logical reports. I assumed I would be able to create an Input Control that just passed a value without any user interaction but I can't work out how to do this? Any ideas?

In a perfect world these implementation details would be hidden away from the user but in this case, from what you've said, I'd guess the gap is that Text Fields in Reports itself need to be able to stream Strings out of Clobs. This strikes me as fairly pointless unless Reports actually implements its report generation via streaming (I only assume this isn't the case based on the requirements for report generation). If this is the case you're never going to avoid the memory issues that JTDS provides this behaviour to avoid, and you just add an extra level of annoyance for users to workaround.