Developer

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:

IRpPrintDriver=interface

The drivers availabe now are:

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:

• Printer resolution may be diferent than screen resolution.
• Fonts on the screen may be drawn different than on the printer.

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.

• One possible enhacement to the engine could be returning the size of the objects as if they print with current printer, it's not difficult but need testing and have this issues:
• If the printer is not installed it should get the screen canvas.
• If the printer is offline (in a network) Windows Systems does not allow opening it, but an error is raised, this situation must be controlled.
• Texts on the screen may appear incorrectly.
• Implementation requires a little more low level access to printer and forget to get it to work in Linux at least until Borland upgrades to Qt 3..

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).

Thanks