Driver architecture of Report Manager
Developer
Driver architecture of Report Manager
Report Manager is a driver-based engine. A report is laid out once into a
device-independent metafile, and a render driver then paints that metafile to a
particular target. Any class that descends from the abstract base class TRpPrintDriver
(declared in rpmetafile.pas) can act as a driver.
The drivers included with Report Manager are:
| Output | Unit | Platform | Notes |
|---|---|---|---|
| rppdfdriver | Windows / Linux | Fixed 72 dpi layout, embedded/subset fonts and complex-script shaping; no graphical-environment dependency, so it runs headless on a server. | |
| SVG | rpsvgdriver | Windows / Linux | Scalable vector output for the web. |
| HTML | rphtmldriver | Windows / Linux | HTML export of the report pages. |
| Windows GDI (preview and printer) | rpgdidriver | Windows | The preview window and direct printing; uses DirectWrite for text shaping. |
| Plain text | rptextdriver | Windows / Linux | Text output, useful for dot-matrix and POS printers. |
| CSV | rpcsvdriver | Windows / Linux | Comma-separated values for import into spreadsheets. |
| Metafile | rpmetafile | Windows / Linux | The native, device-independent page format; can be re-rendered later by any other driver. |
Lazarus/FPC builds add an LCL driver (rplcldriver) for preview and printing,
and the .NET / .NET Core libraries provide their own rendering. The legacy Kylix/Qt
driver (rpqtdriver) and the Windows-only Excel export (rpexceldriver)
are kept only for backward compatibility.
The Web Report Server and the TCP Report Server always render with the PDF driver, which has no dependency on a graphical environment and therefore runs as a console service on Linux.
How a driver is used
While calculating the report the engine asks the driver for text and graphic sizes; once the layout (the metafile) has been computed, the same driver – or a different one – paints each page. Because the metafile is device-independent, a report can be calculated with one driver and printed with another: a metafile generated by the web server, for example, can be printed later with metaviewxp on Windows or metaview on Linux.
The size queries are:
procedure TextExtent(atext:TRpTextObject; var extent:TPoint); virtual; abstract;
procedure GraphicExtent(Stream:TMemoryStream; var extent:TPoint; dpi:integer); virtual; abstract;
The engine uses them to reserve space for auto-expanding and auto-contracting sections and components.
Choosing an output driver
Every driver paints the same metafile, so the page geometry is identical; the drivers differ in fidelity and in their intended use:
- PDF – the most faithful portable output and the recommended format for archiving, e-mail and the report servers; it works at a fixed resolution, so it looks the same in every viewer.
- Windows GDI – on-screen preview and direct printing on Windows.
- SVG / HTML – for embedding the report in web pages.
- Plain text / CSV – data-oriented output (dot-matrix, POS, import into a spreadsheet); fonts, colors and graphics are not preserved.
- Metafile – store the report once and render it later to any of the above.
Matching printer and PDF output
Text can be measured with the screen canvas or with the target printer. Screen and printer resolutions differ and a font may be drawn slightly differently on each, so the preview, GDI printing and PDF output could previously show small differences in text width.
The Printer Fonts option in page setup now offers a Recalculate report mode that recomputes the layout using the target device metrics (a glyph-exact pipeline). With it the printer and PDF output are practically identical. Metafiles produced this way are stored in format 4.1 and keep the glyph-exact information, so they print the same when re-rendered later. The PDF driver already knows exact font sizes and works at a fixed 72 dpi resolution, so PDF is consistent across viewers.