Driver Architechture of Report Manager

Report Manager engine is a driver based print engine. That is: you can implement a driver and you get the desired output.

The driver is defined as an interface in the unit rpmetafile.pas, so any object or component can implement it:


The drivers availabe now are:

Class Unit Component Platform
TRpGDIDriver rpgdidriver TVCLReport Windows
TRpQtDriver rpqtdriver TCLXReport Linux/Windows
TRpPDFDriver rppdffriver TPDFReport Linux/Windows
-- rpexceldriver -- Windows
TRpTextDriver rptextdriver -- Linux/Windows
-- rphtmldriver -- Linux/Windows

The Web Report server and TCP Report Server always work with TRpPDFDriver, in Linux, it has no dependences on X Server, so it can run in console mode, as a service.

The engine asks the driver texts sizes, and others while calculating the report, once calculated (metafile report), the engine use the driver for printing or previewing the report. This proces is done in a page by page basis when the report is not marked as a 'two pass report'.

The excel and html driver calculate sizes with the pdfdriver, they can only process metafiles, not reports.

Note that a report can be calculated using a driver, then print or preview using another driver, that is the case of generating metafiles using web report server, and print this metafiles using metaview in Linux (QtDriver) or metaviewxp in Windows (GDIDriver).

So a report can be processed directly using one of the drivers above or you can also use any of the drivers to generate a Report Metafile, this is a file that contains all the info necessary to print or display the pages using also same drivers, is the same concept as a PDF File, but it includes additional information like destination printer name, custom paper sizes... A report metafile can be sent to the ActiveX control plugin so it shows or prints it.

The engine calls driver functions, to know the size of a text or a graphic.

procedure TextExtent(atext:TRpTextObject;var extent:TPoint);stdcall;
procedure GraphicExtent(Stream:TMemoryStream;var extent:TPoint;dpi:integer);stdcall;

When you work with variable sized sections and components, using properties like AutoExpand or AutoContract, the engine will calculate space for sections and components calling this driver functions.

The internal implementation of TRpGDIDriver and TRpQtDriver have a special property: toprinter, if this property is set the functions about object size are asked to the printer driver (Printer.Canvas and QPrinter.Canvas), and the result may be different than the result using the screen canvas (Preview Window), so you can
obtain different output results.

That is because:

The PDF driver knows exact size about Fonts and work at a fixed resolution (72 dpi), so the result should be the same in all PDF viewers.

About font sizes and Truetype PDF Output.

Having a symple sentence covering near one line and a Truetype Font selected at point size 26.I see some differences between:
1- Report Manager preview.
2- Printing from Report Manager engine.
3- Exporting to PDF Output from Report Manager and print out(current development implementation)
4- Printing from Openoffice
5- Exporting from OpenOffice to PDF and print out.

- The 1 print (screen) have the larger width, with a diference of about 2 chars over the output numer 2 (printing from Report Manager engine).
- The 4 option (Open Office) output have a larger result in print out than number 2 but less than number 1 (just 1 char diference with number 2)
- The 5 (exporting from OpenOffice to PDF) coincides exactly with option 2 and 3, but shows printout in OpenOffice gives different result than Export to PDF then print out (not a acrobat reader problem)
- The exactly same preview and print is given by acroread.

That shows the sizing and previewing of TrueType fonts are not perfect for experienced programs and libraries, in Microsoft Windows something similar happens (but only preview differs).
Anyway it's possible an exact implementation in Report Manager (preview same as printout), but this requires to replace the call to Qt libraries to draw a block of text to draw words or letters, giving more complexity to the engine (Microsoft Windows GDI call must be also replaced).

So current implementation (this issue was present also before Truetype embedding) have the limitation of previewing multiple line texts not producing exactly same output at screen and in printout, take care that the printout well be more precise. You will see the issue occasionally when previewing a single text that fills lot of lines in the same page.

I say you this to ensure you know this is a Windows Win32 API limitation and Qt library limitation (just like the full justify missing feature), and not easy to implement (replace that apis with correct ones).