View Full Version : Mixing landscape and portrait in a report.

05-26-2002, 11:13 PM
Are there plans to allow multiple sections, with different page layouts, within a report. I am looking at incorporating charts from JFreeChart into reports and would like to print the charts landscape whilst printing the data portrait.

Martin Smith

05-27-2002, 03:10 AM
Currently, there are no such plans, but ... how would you like to incoperate the charts?
Where do you print them - on GroupHeader/Footer or ReportHeader/footer? You print them on a separate page, I assume. Next Question: How do include them? As AWT-Image? or as geneated Image-File using a ImageReference?

You may wondering, why I'm asking this: I thought about including JFreeChart support, but then I had no fast and clean way of including it now, so I moved the problem to a later time. If you have a solution or ideas/hints for the problem, I would be glad to include your input in the project.

Have more fun,
said Thomas

05-27-2002, 06:14 PM
Hi Thomas / Martin,

I'd like to see some ways of incorporating charts into JFreeReport. Here's my suggestions, and I hope to do some work on these when I get a chance...

Add a new <CHART> report item that expects to receive a fully initialised JFreeChart object from a field or function. You could add this item to any report band and the chart could come from:

1) the report's TableModel : in the current implementation, this means one chart per row (ItemBand), which wouldn't always be that useful...but this would be more useful as the master-detail reporting evolves;

2) a user defined report property : you could just add any old JFreeChart as a user defined report property and have it printed in the report header or footer. This would meet a small subset of reporting requirements (where there is just one chart required per report), and would be easy to implement.

Notice that for both these cases the charts come complete with their own data already initialised...it's not a case of reading any data from the TableModel to generate the chart (which would be possible, but more difficult to implement).

Back to the original question about mixing landscape and portrait pages. I gave some thought to adding a CompositeReport class to the library...this would keep an ordered list of JFreeReport objects (all just regular reports), and print them in sequence, each with their own page format (which would need to be added to the report definition) but overriding the page numbering to create a single 'composite' report. This might be helpful.

Any thoughts?

Dave Gilbert

05-28-2002, 01:39 AM
My thinking regarding implementation was close to yours David. I thought about the chart being a report element allowing multiple reports per page etc. The only real difference was that I would like to be able to define a chart dynamically in the XML definition something along the lines of

<ChartElement type="TIMESERIES" verticalLabel="Return" horizontalLabel = "rebalance date" .....>
<Series name="Portfolio a" datavalue="column x from table model">
<Series name="Portfolio b" datavalue="column y from table model">
<Series name="Portfolio c" datavalue="column z from table model">

This is more complex but could probably be handled by creating a FactoryObject that was passed the ChartElement Element and the underlying TableModel.

This made me wonder about the ability to define multiple TableModels within a report ( but that is a very much more complicated proposition).

05-28-2002, 04:30 AM
Hi Martin, Hi, David,

creating such a ChartElement looks promising, at least for the first time. But I have a .. hm bad feeling on doing a half job, because this will create a feature which will shortly after creation become obsolete, but for the sake of backward compatibility we would have to include and maintain it into the following releases.

So what about this: We include a userdefined element with drawing capabilities as a plugin for feeding Images/Charts and other userdefined elements into the report. This will give a small but fast solution to the problem of integrating any other content. Included elements have to implement a to be defined interface for interacting with JFR. This general approach will (hopefully) remain valid for a long time.

As far as I see, one thing that is missing, is an easy to use ChartDefinition language. Once such a definition exists, things would be easier to include in out project, and this leads to the Task of:

Extending JFreeChart with a similiar parser interface as JFreeReport has, so that we could reuse the datasources we allready have. And this would/could lead into a report generation where grouping function results can be displayed as chart at the end of the report, on the fly of course, or where .. as let your imagination flow, what one could do with such feature.

The chart definiton can be included as separate xml file in the report definition and gets loaded when the report is parsed (as it is done with image files already).

Well, but to the original question: splitting a report into multiple reports will make things like grouping functions very difficult. The same applies to using multiple tablemodels. As table models are just a logical structure, it is easy to define a generic tablemodel, which will do the same as a join in SQL. Such a model along with some filtering/querying capabilites will be included into one of the next releases.

But a composite report will be usefull. It is not yet posible using the current implementation, but what about stacking a JFreeReport object into another report as ItemBand replacement? Shouldn't this construct do the job of master/detail reports and composite reports?

And extending bands with a pageformat property would give the posibility to define different pageformats for groups or itembands. This would give users the ability to create landscape itembands and printing portrait headers (posibly with charts included :)).

Required for this feature is just a working page format definition. But this is a planed - and defined - but not yet working feature.