A report generator uses a tabular data source, which contains rows and columns of data. The columns have labels or names. (An SQL database query is such a tabular data source.) It also uses some kind of description that specifies how to display the data. The input data is transformed into various output formats, some for human viewing, some for further machine processing. Such output formats may be PDF, HTML, XML, plain text or CSV.

The XML file format is widely used. It can describe structured data in a hierarchy with names for its sections or "nodes".

OpenCReports uses an RLIB-compatible report description with extensions. See Report XML description and the RLIB documentation

The Low level C API allows creating a report purely via program code. The High level C API allows loading an XML report description that contains all details about the report, including database access. Mixing the high and low level APIs allows a balance anywhere between the two extremes. For example, load the report description, which contains the complete layout, and pass database access details via program code. As a comparison, RLIB's API and report description allowed neither extremes: it relied on the report description to provide the layout, with data access and other supplementary details controlled from programming code.

OpenCReports uses a Flex/Bison based expression parser. The expression grammar doesn't allow incorrect expressions. See the Expressions chapter.

OpenCReports does some expression optimization to reduce runtime cost of computing expression values. For example, in a*2/3 the part 2/3 is two constants in a division. This is precomputed into a single constant as an optimization. Naturally, only mathematically valid optimizations are performed.

OpenCReports supports standard report variables for calculating sums, minimum, maximum and average values or custom defined ones. See Report variables

Report variables can also be used as manual expression optimization. A common subexpression can be moved to a report variable from multiple expressions, which in turn is computed once, and its result is used in the expressions referencing it.

A report break is a form of data grouping based on value changes. A break (break boundary) occurs when the value of a watched expression changes from one data row to the next. OpenCReports supports report breaks defined on arbitrary expressions. Report variables can reset their value on break boundaries. See Report breaks and Breaks.

OpenCReports has many operators and functions to be used in expressions. See Operators and functions in the Expressions chapter.

Custom functions can also be added to a report by programming code. Custom functions may override stock functions.

OpenCReports exclusively uses UTF-8 for strings. Input data must be in UTF-8 and output formats also use UTF-8. This allows text from different languages appear in the same report, provided that an applicable font is available.

OpenCReports uses a high precision numeric data type. This allows scientific computation or monetary calculations even with late stage hyperinflation prices. See Numeric constants in the Expressions chapter and the Numeric behavior related functions part in the Low level C API chapter.

OpenCReports handles both timestamp and time interval data types. The latter allows adding or subtracting a custom time period to and from timestamp data. See Datetime constants in the Expressions chapter.

For maximum portability, databases provide their data in strings. They also indicate the column type. OpenCReports detects the columns' data type and applies the conversion automatically.

In the report output, fields may have a fixed width in which they are displayed. Some field values are longer than the field width. When displaying them in a single row, fields may be left-, right- or center-aligned to show the interesting part of the value or for visual reasons.

Fields longer than the designated width may be wrapped either at word or character boundaries. This way, they become multi-row fields. Multi-row fields are also called "memo" fields. Such fields may wrap lines at word boundaries or break words at some character. Multi-row fields have configurable line number limits. Memo fields can break over to the next column or to the next page. Hyphenation is done automatically when using character wrapping. Memo fields may also use justified alignment.

OpenCReports supports both single- and multi-column layout in its PDF output format. Other output formats may only use single-column layout.

OpenCReports implements an RLIB compatibility mode for sizing report layout details, which uses a mix of units, mostly based on character widths (making it dependent on the font size used) mixed with points (1/72th inch) for some report elements.

OpenCReports also has a new, consistent size calculation method where everything is measured in points (1/72th inch).

OpenCReports supports both fixed and proportional fonts even with using the RLIB compatible size settings.

OpenCReports supports several output formats: PDF, HTML, CSV, TXT, XML and JSON.

The unit tests ensure that OpenCReports' features keep working when adding new features or fixes. Units tests exercise many aspects of the high and low level API, report description handling, runtime behavior and output generation.

OpenCReports uses LibXML2, utf8proc, MPFR, libpaper, libcsv, yajl, Cairo, Pango, librsvg2, gdk-pixbuf2, PostgreSQL, MariaDB and unixODBC.

For running the unit tests, Ghostscript and compare from Imagemagick are also needed.

xmllint, xsltproc and fop are used to generate the documentation.