FAQ’s & Features
Report or document templates are standard in reporting applications. They define the layout of the documents that the report-filling process produces. Like other document template engines, PDFReporter uses document templates structured in multiple sections. Each section type has its own characteristics and behavior. Section types include title, summary, page and column headers and footers, group headers and footers, and details. Each section is made of individual elements like lines, rectangles, static and dynamic text fields, images.
FAQ’s and Feature descriptions
pageWidth=”595″ pageHeight=”842″ orientation=”Portrait”
If you decide to use the Landscape layout for your A4 document, you must be sure to modify the page width and page height accordingly, as follows:
pageWidth=”842″ pageHeight=”595″ orientation=”Landscape”
This is because PDFReporter has to know exactly the absolute width and height of the pages it will draw on, and does not necessarily consider the value supplied in the orientation attribute, at least not at report-filling time. This orientation attribute is useful only at report-printing time to inform the printer about the page orientation, and in some special exporters. The default page orientation is “Portrait”.
The name attribute of a <style> element is mandatory. It must be unique because it references the corresponding report style throughout the report. You can use isDefault=”true” for one of your report style declarations to mark the default for elements that do not or cannot have another style specified.
Each report style definition can reference another style definition from which it will inherit some or all of its properties. The style attribute specifies the name of the parent report style.
Sometimes users need to change a report element style at runtime based on certain conditions (for example, to alternate adjacent row colors in a report detail section). To achieve this goal, you can set some style properties to be enabled only if a specified condition is true. This is done using conditional styles.
The JEval is used for writing report expressions.
For example, you could pass to the report engine the name of the user who launched the report filling operation if you want it to appear on the report, or you could dynamically change the title of your report.
The supplied values for the report parameters can be used in the various report expressions, in the report SQL query.
For instance, the detail section is rendered for each record in the data source. When page breaks occur, the page header and page footer sections are rendered as needed.
Sections are made of one or more bands. Bands are portions of the report template that have a specified height and width and can contain report elements like lines, rectangles, images, and text fields. These sections are filled repeatedly at report generating time and make up the final document.
The title is the first section of the report. It is generated only once during the report filling process and represents the beginning of the resulting document.
The title section precedes even the page header section. To print the page header before the title section, put the elements on the page header at the beginning of the title section as well.
The page header appears at the top of each page in the generated document.
The column header appears at the top of each column in the generated document.
For each record in the data source, the engine tries to generate a detail section. The detail section can be made of multiple bands.
The column footer appears at the bottom of each column in the generated document. It never stretches downward to acquire the content of its containing text fields.
The page footer appears at the bottom of each page in the generated document. Just like the column footer section, the page footer never stretches downwards to acquire the content of its containing text fields and always retains the declared fixed height.
The summary is generated only once per report and appears at the end of the generated document, but is not necessarily the last section generated. This is because in some cases the column footer and/or page footer of the last page follows it.
If present, the last page footer, this section replaces the normal page footer section, but only on the last occurrence of the page footer, which might not be the last page if the summary is present and it overflows on multiple pages or it is rendered alone on its own last page. So it behaves more like the last page footer than the footer of the last page.
The background is a special section that is rendered on all pages and its content placed underneath all other report sections. Normal report sections are rendered one after the other, but the background section does not interfere with the other report sections and can be used to achieve watermark effects or to create the same background for all pages.
Since a report template usually uses only a few types of fonts shared by different text elements, there’s no point forcing JRXML report template creators to specify the same font settings repeatedly for each text element. Instead, reference a report-level font declaration and adjust only some of the font settings, on the spot, if a particular text element requires it.
When creating reports in different languages for export to PDF, make sure that you choose the appropriate character encoding type. For example, an encoding type widely used in Europe is Cp1252, also known as LATIN1. Examples of some other possible encoding types are shown below.
Latin 2: Eastern Europe Cp1250
Windows Baltic Cp1257
Simplified Chinese UniGB-UCS2-H,UniGB-UCS2-V
Traditional Chinese UniCNS-UCS2-H,UniCNS-UCS2-V
Japanese UniJIS-UCS2-H, UniJIS-UCS2-V, UniJIS-UCS2-HW-H, UniJIS-UCS2-HW-V
Korean UniKS-UCS2-H, UniKS-UCS2-V
One possible value of the stretchType attribute, available for all report elements, is RelativeToTallestObject. If you choose this option, the engine tries to identify the object from the same group as the current graphic element that has suffered the biggest amount of stretch. It will then adapt the height of the current report element to the height of this tallest element of the group.
However, for this to work, you must group your elements. To do this, use the <elementGroup> and </elementGroup> tags to mark the elements that are part of the same group.
When the user clicks a hyperlink, he or she is redirected to a local destination within the current document or to an external resource. Hyperlinks are not the only actors in this viewer-redirecting scenario. You also need a way to specify the possible hyperlink destinations in a document. These local destinations are called anchors.
There are no special report elements that introduce hyperlinks or anchors in a report template, but rather special settings that make a usual report element a hyperlink and/or an anchor.
In PDFReporter, only text field, image, and chart elements can be hyperlinks or anchors. This is because all these types of elements offer special settings that allow you to specify the hyperlink reference to which the hyperlink will point to or the name of the local anchor.
A good example of a generic element use case is someone wanting to embed movies in reports exported to HTML format. PDFReporter has built in support for displaying text and images, but there is no built in element for displaying movies. But this feature can be implemented.
Since subreports are normal reports themselves, they are compiled and filled just like other reports. This means that they also require a data source from which to get the data when they are filled. They can also rely on parameters for additional information to use when being filled.
The <returnValue> element is used inside <subreport> to specify values to be returned from the subreport.
A value returned from a subreport can simply be copied into the target master report variable, or it can be subject to a certain type of calculation made on the variable.
Crosstabs are useful because they are easy to understand, can be used with any level of data (nominal, ordinal, interval, or ratio), and provide greater insight than single statistics.
Crosstabs use an internal calculation engine for bucketing and preparing the aggregated data they display. However, sometimes it is useful to pass single values from the containing report and display them inside the crosstab. This would be the case for some crosstab header titles.
Any number of crosstab parameters can be declared inside the crosstab element. Each parameter has its own name and type, as well as its own expression used at runtime to obtain the value to pass into the crosstabs.
PDFReporter architecture allows to include barcodes. The implementation that permit barcodes to be embedded in reports only needs to implemented in the PDFReporter library.
But simple variable expressions cannot always implement complex functionality. This is where scriptlets come in. Scriptlets are sequences of a code that are executed every time a report event occurs. Through scriptlets, users can affect the values stored by the report variables. Since scriptlets work mainly with report variables, it is important to have full control over the exact moment the scriptlet is executed.
This feature is in an experimental stage.
There are five exporter parameters for this:
IS_ENCRYPTED: When set to Boolean.TRUE, this parameter instructs the exporter to encrypt the resulting PDF document. By default PDF files are not encrypted.
IS_128_BIT_KEY: The PDF exporter can encrypt the files using either a 40-bit key or a 128-bit key. By default, it uses a 40-bit key, but if you set this flag to Boolean.TRUE, it can be configured to use a 128-bit key for stronger encryption.
USER_PASSWORD: This parameter specifies the password required from a normal PDF file user to access the document.
OWNER_PASSWORD: This parameter specifies the password required from the owner of the PDF file to access the document. The owner usually has more permissions. If this password is not set, an arbitrary string will be used when encrypting so that access is denied to all would be owners.
PERMISSIONS: This exporter parameter accepts values representing the PDF permissions for the generated document. The open permissions for the document can be AllowPrinting, AllowModifyContents, AllowCopy, AllowModifyAnnotations, AllowFillIn, AllowScreenReaders, AllowAssembly, and AllowDegradedPrinting. Permissions can be combined by applying bitwise OR to them.
The PDF_VERSION exporter parameter accepts values, but only a few values are recognized as valid, so users have to use constants to point to the PDF specification version.
Since version 1.5, the PDF format supports compression. By default, the PDF exporter in PDFReporter does not create compressed PDF documents, but this feature can be turned on using the IS_COMPRESSED exporter parameter. Note that because compressed PDFs are available only since PDF version 1.5, the PDF version of the resulting document is set to 1.5 automatically if compression is turned on.
Through an intuitive and rich graphic interface, PDFReporter Studio lets you rapidly create any kind of report very easily. PDFReporter Studio enables engineers who are just learning this technology to access all the functions of PDFReporter, as well as helping skilled users to save a lot of time during the development of very elaborate reports.