BIRT: Fit to whole page in report design? - reporting

I have a report and want to fix it to 1 page (A4) regardless of the number of rows in the table. Usually it's 10 rows but can be more in some cases.
Anyway I need to use BIRT in a fixed context (3rd party application), eg. no option to adjust the BIRT viewer or url params. Therefore how can I add this option to my report design so that it is applied automatically?

I don't think it is possible to force a render option from the report-design. If it was it would probably achieved by using this code fragment from "beforeRender" script of the report:
importPackage(Packages.org.eclipse.birt.report.engine.api);
reportContext.getRenderOption().setOption(IPDFRenderOption.PAGE_OVERFLOW,IPDFRenderOption.FIT_TO_PAGE_SIZE);
I tried it, it appears at this stage the BIRT task has already applied render options and therefore this new value is ignored.
If you have access to the source code of this third party app it is quite easy to add a "Fit to" PDF render option.
Otherwise you will have to change the report-design and make it a little bit more dynamic: there are many design tips allowing to fit a report in a single page, one of them is to change the height of some items by script depending on the number of rows of the table.

Related

Overlap Subreports SSRS

I was trying to create one report with several pages doing this:
I've created like 3 reports with different embedded datasets (each report has nothing to do with the others).
I've created a main report where i put the 3 subreports, overlaying them.
In SSRS web view i can change the the pages in order to see each subreport in a different page.
The problem is when i tried to export the report in PDF, there is not a "page break" so the first page contain all the reports overlayed.... this is a big issue....
Is there a way to fix this?
You can enclose sub reports in a rectangle and provide page break properties to the rectangle.
1st sub-report should be within 1st rectangle and as is.
You can also make sure, sub-reports are one-by-one in the design for proper page breaks.

Hide/remove options from a view's grid header filtering

I've been looking for an approach to remove unwanted values from a views grid column filtering dropdown but I'm not sure if its even possible.
A specific view in our app only displays results where the column will contain 5 values, however the column option set has 20+. Is it possible to remove the unwanted 15 values from being displayed when the view's filter by function is used?
This documentation does not mention any way the values can be hidden.
I have added a web resource to a view column before, to change text values into an image, however I don't think this is an applicable place to add a script to hide filter by values.
I have developed plugins so not against using this medium if the approach works and does not introduce a performance hit.
Unfortunately that header filter is not open for customization/configuration. Though MS mention it as Excel like filter, it is not going to give the filter options for only values from current list. It will load the full options list.
When we had such requirements in the past - we have developed a PCF control with grid + filters and used it instead.

Oracle Apex Interactive Report vs Interactive Grid

I've used them both, but I can't seem to find any advantage to Report vs Grid.
Grid gives the developer much more options and flexibility, and I didn't find any place that really compares pros and cons for each.
Any Reason to use Report over Grid?
Thanks
I developed a set of applications in APEX from 5.1 to 19c and I'd like both, IG and Reports, however I use them in different scenarios:
Obviously if you want a IG for manipulation of data, then IG is your only option.
If you want a Report, but you want to give the user endless options with it like download the content in csv, apply filters, create rules with the data visualisation like applying colours to rows that match different criteria. Then IG is your option
If the report is static and you don't want any interaction on it, then use Report, it is much better for this scenario.
Hope it helps!
I use
reports for reporting purposes - let users view data
interactive grids to view data in a grid, along with possibility to edit existing values or add new rows right here
Although you can make both do what the "other" does (with more or less effort), their "natural" roles are as I previously said. To me, at least.
OK I found one big advantage to working with Interactive Report, when working with Files/Images.
Grid does not contain "Download BLOB" nor "Display Image" options in types, which makes it really hard to work with, and creating many compatibility problems.
I've wasted 2 days trying to work with files in Grid but still failed, while in Report I managed to do that in a couple of hours and it works.
For all other types, I guess Grid is better.

suggestion where to look to find why my report has extra blank pages

I am on Msoft SQL Server Report Builder, v15.0
I have a multi page report that no matter that forces a blank page every 2nd page.
I have searched through the tablix properties, report properties, header & footer properties and have not found a culprit yet.
I fear that there are somehow some hidden pieces that are causing this issue, but I do not know how to be able to see the hidden pieces.
I have opened the .rdl file up in notepad++ and started walking through the code, but I am not certain where I should look at in there that would cause my problem.
It is a 10 column report that is generated from a dataset culled down, but the report has 3 calculated fields in it, including a column which generates a ranking number.
If you know of a explicit piece of code I should search for that would be awesome, but I know that is a needle in a snowpile.....
Found finally what I had done...
my durn body was the same width as the page sheet so it was pushing the margins off and creating a new page.
Here is a good walk through of what I found.....
http://www.keepitsimpleandfast.com/2009/12/export-of-reporting-server-reports-to.html

Dynamic Text Control begins on new page when total data for the control exceeds an entire page

BIRT 3.71v20110905
One of my data fields is a CLOB with html tags. I'm using the Dynamic Text Control in my report. This specifically happens when:
The Dynamic Text Control content type is to HTML or Automatic
in my case since I have html tags in the data. (Problem does not occur if I set the content type to Plain, but then the HTML tags show up in the report output as text.)
and
The total amount of data to be displayed by the control is more than one full page on its own
(without taking into account spacing used by other controls). If the
total amount of data to be displayed by the control is less than one
full page but can't all fit on the current page, it works as expected (meaning it displays what it
can on the current page and wraps the rest correctly onto the next
page.)
Is this a bug in the calculation for the DTC pagination?
Additional notes - I encountered this while trying to use a sample report that inserts a page break as needed between groups for duplex printing. It works great under most circumstances, but not when this DTC pagination issue rears up. ( GroupAlwaysStartsOnOddPage.rptdesign )
Sorry to disappoint, but this is a known issue and has not yet been resolved. At least not in the version of BIRT that Maximo is using.
What I tend to do is break the dynamic text where possible, experiment until I get the largest possible part on one page and put the rest into another dynamic text field.
This is obviously only a work around, but as far as I know there is not much else that you can do.
We ran into this problem with a dynamic text field containing HTML content coming from IBM Maximo long description fields. The report was designed in BIRT 3.7.1 Designer.
We were able to work around the duplication bug by changing the layout from Fixed to Auto. With Auto layout, it is also not necessary to change the Display setting of the field to "inline" (which we previously had to do to allow it to flow between pages without creating an initial page break).
In our case, changing the layout to Auto did not have negative effects on the appearance or geometry of our report.

Resources