PDF::ReportWriter
PDF::ReportWriter is designed to create high-quality business reports, for archiving or printing.
For a full example of all the features of PDF::ReportWriter, please see the Axis Not Evil demo application package, which is distributed separately, at http://entropy.homlinux.org/axis_not_evil Formatting in man pages is difficult, as is maintaining large examples in multiple places. Appologies.
A field definition can have the following attributes
The 'name' is used when rendering field headers, which happens whenever a new group or page is started. You can disable rendering of field headers by setting no_field_headers in your data definition.
The width of the field, as a percentage of the total available width. The actual width will depend on the paper definition ( size and orientation ) and the x_margin in your report_definition.
The font to use. In most cases, you would set up a report-wide default_font. Only use this setting to override the default.
The font size. Nothing special here...
The colour to use for rendering data ( and also group headers / footers ).
The colour to use for rendering data headers ( ie the field names ).
The text to display in the field.
A hash with details of the image to render. See below for details.
A user-defined sub that returns a colour based on the current data ( ie receives 1 argument: the current value )
Possible values are "left", "right" and "centre" ( or now "center", also ).
Possible values are "sum" and "count". Setting this attribute will make PDF::ReportWriter carry out the selected function and store the results ( attached to the field ) for later use in group footers.
This key turns on formatting of data. The only possible values currrently are 'currency' and 'currency:no_fill', which are achived via Number::Format ( which spews warnings everywhere - they're harmless )
A hash containing details on how to render the background of the cell. See below.
You can define images in any cell ( data, or group header / footer ). The default behaviour is to render the image at its original size. If the image won't fit horizontally, it is scaled down until it will. Images can be aligned in the same way as other fields, with the 'align' key.
The images hash has the following keys:
The full path to the image to render ( currently only supports png and jpg ) This key is the only required one
A boolean value, indicating whether the image should be scaled to fit the current cell or not. Whether this is set or not, scaling will still occur if the image is too wide for the cell.
You can hard-code a height value if you like. The image will be scaled to the given height value, to the extent that it still fits length-wise in the cell.
You can define a background for any cell, including normal fields, group header & footers, etc. For data headers ONLY, you must ( currently ) set them up per data set, instead of per field. In this case, you add the background key to the 'headings' hash in the main data hash.
The background hash has the following keys:
Current options are 'box' or 'ellipse'. 'ellipse' is good for group headers. 'box' is good for data headers or 'normal' cell backgrounds. If you use an 'ellipse', it tends to look better if the text is centred. More shapes are needed. A 'round_box', with nice rounded edges, would be great. Send patches.
The colour to use to fill the background's shape. Keep in mind with data headers ( the automatic headers that appear at the top of each data set ), that you set the *foreground* colour via the field's 'header_colour' key, as there are ( currently ) no explicit definitions for data headers.
Groups have the following attributes:
The name is used to identify which value to use in rendering aggregate functions ( see aggregate_source, below ). Also, a special name, "GrandTotals" will cause PDF::ReportWriter to fetch *Grand* totals instead of group totals. This negates the need to have an extra column of data in your data_array with all the same value ... which is the only other way I can see of 'cleanly' getting GrandTotal functionality.
The data_column refers to the column ( starting at 0 ) of the data_array that you want to group on.
Group headers and footers are defined in a similar way to field definitions ( and rendered by the same code ). The difference is that the cell definition is contained in the 'header' and 'footer' hashes, ie the header and footer hashes resemble a field hash. Consequently, most attributes that work for field cells also work for group cells. Additional attributes in the header and footer hashes are:
This is used to retrieve the results of an aggregate_function ( see above ).
Possible attributes for the report defintion are:
The path to the destination ( the pdf that you want to create ).
The only paper types currently supported are A4 and Letter. And I haven't tested Letter...
portrait or landscape
An array of font names ( from the corefonts supported by PDF::API2 ) to set up. When you include a font 'family', a range of fonts ( roman, italic, bold, etc ) are created.
The name of the font type ( from the above list ) to use as a default ( ie if one isn't set up for a cell ).
The default font size to use if one isn't set up for a cell. This is no longer required and defaults to 12 if one is not given.
The amount of space ( left and right ) to leave as a margin for the report.
The amount of space ( top and bottom ) to leave as a margin for the report.
The data definition wraps up most of the previous definitions, apart from the report definition. My goal ( with a future release ) is to support unlimited 'sections', which you'll be able to achieve by passing new data definitions and calling the 'render' method. Currently this does not work, but should not take too much to get it going.
Attributes for the data definition:
Whether to render cell borders or not.
Set to disable rendering field headers when beginning a new page or group.
This is your field definition hash, from above.
This is your group definition hash, from above.
This is the data to render.
Object constructor. Pass the report definition in.
Renders the data passed in You can call 'render_data' as many times as you want, with different data and definitions
Saves the pdf file ( in the location specified in the report definition ).
Dan <dan@entropy.homelinux.org>
I think you must be mistaken.
This module is part of an umbrella project, 'Axis Not Evil', which aims to make Rapid Application Development of database apps using open-source tools a reality. The project includes:
Gtk2::Ex::DBI - forms
Gtk2::Ex::Datasheet::DBI - datasheets
PDF::ReportWriter - reports
All the above modules are available via cpan, or for more information, screenshots, etc, see: http://entropy.homelinux.org/axis_not_evil
To install PDF::ReportWriter, copy and paste the appropriate command in to your terminal.
cpanm
cpanm PDF::ReportWriter
CPAN shell
perl -MCPAN -e shell install PDF::ReportWriter
For more information on module installation, please visit the detailed CPAN module installation guide.