Sunday, February 19, 2012

Hiding columns does not shrink report

I am trying to hide columns on a report depending on specific parameters.
Although the columns become invisible and the table resizes as per the data,
the report width still remains the same. Hence, when the report is exported
to pdf, although the data fits on one screen, it still prints one extra empty
page. I do not want to use a matrix, because its a complex report which has
already been developed and I do not have enough time for re-development.The size of the report will be picking up on the body width. [If you can't
see this go to the property window, click the drop down at the top and select
'body']
So if you have 50 columns but are only showing 3 it will still default to
the width of the 50 columns - the body is always outside of this.
You could try having a landscape page, using smaller fonts, removing
uneccessary decimal places, rotaing column headers to be vertical, using
abbreviations in addition to making the column widths as small as they will
go.
"Madhusudan" wrote:
> I am trying to hide columns on a report depending on specific parameters.
> Although the columns become invisible and the table resizes as per the data,
> the report width still remains the same. Hence, when the report is exported
> to pdf, although the data fits on one screen, it still prints one extra empty
> page. I do not want to use a matrix, because its a complex report which has
> already been developed and I do not have enough time for re-development.|||Actually, your suggestions have already been implemented. Right now, there is
hardly any space in the report for additions. Whatever was possible has
already been made.
I was able to make out that the issue was due to the body width. Is there a
way to dynamically change the body width at runtime?
Also I have noted that, if I remove the page footer, the white space is not
printed on the html report. In this case the whole report resizes to the size
of the table. The report that I am working on, does not have a page header,
but it does have a page footer which just contains the page no. (page x of
y).
Thanks and Regards
Madhusudan
"adolf garlic" wrote:
> The size of the report will be picking up on the body width. [If you can't
> see this go to the property window, click the drop down at the top and select
> 'body']
> So if you have 50 columns but are only showing 3 it will still default to
> the width of the 50 columns - the body is always outside of this.
> You could try having a landscape page, using smaller fonts, removing
> uneccessary decimal places, rotaing column headers to be vertical, using
> abbreviations in addition to making the column widths as small as they will
> go.
> "Madhusudan" wrote:
> > I am trying to hide columns on a report depending on specific parameters.
> > Although the columns become invisible and the table resizes as per the data,
> > the report width still remains the same. Hence, when the report is exported
> > to pdf, although the data fits on one screen, it still prints one extra empty
> > page. I do not want to use a matrix, because its a complex report which has
> > already been developed and I do not have enough time for re-development.|||Madhusudan,
did you get a solution to this? I have the same issue.
Regards,
Andrew|||No Andrew, I did not get any answer to this question. Finally I had to create
a new report with the extra columns and show the respective report file
depending on the parameter selected. I know that, this would cause
maintenance issues as both the files would have to be updated if any changes
had to be done, but it was the only way out at that moment.
Regards,
Madhusudan
"Duke (AN247)" wrote:
> Madhusudan,
> did you get a solution to this? I have the same issue.
> Regards,
> Andrew
>|||Thanks Madhusudan,
that was my fallback plan. I was thinking of making the maintenance easier
by writing a utility application that would take the master version of a
given report, and then output extra RDL files with the hidden columns removed
from the RDL and the page resized.
Cheers,
Andrew

No comments:

Post a Comment