Exporting With FastReports
One of the most important abilities of FastReports is exporting reports to various kinds of graphical and textual document formats. At this moment, there are numerous formats, from the popular pdf through the little-known cgm. FastReports supports more than ten different formats, coverings needs to a large extent. Each of these formats has its own peculiarities, that must be noticed when designing a report and its further exporting. All these formats can be divided into several groups, each group incorporating similar formats.
Typical species of of table formats are xls, rtf and html. The exporting process to any table format takes at least two steps:
- Transforming a report to a matrix
- Transforming the matrix into a required format
If you want the result of exporting to match your expectations, this feature should be noticed when designing the report. A few common recommendations will be given, well applicable either in the case of exporting to rtf or in the case of exporting to any other table format.
The first and the most fundamental advice is that you visualize how your report will be after its transformation to the matrix, as said earlier. For this purpose, just mentally draw both horizontal and vertical lines through each corner of each component on the report. This
component can be a text field, a picture or something. On the example two components can be seen: a picture and a text field. Red dotted lines are drawn through each corner of each component. After that, the report will be transformed into a matrix wherein all components are represented as a set of non-overlapping rectangular cells and each of these cells
belongs to a single component. On the other example
one of possible alternative allocations is shown: three blue cells belong to the text field and four red cells belong to the picture.
All other cells are “free”. Let us export the report to xls. The xls export engine must decide how to merge neighbouring cells. Merging of cells is done, in fact, in a casual way, sometimes producing unexpectable results. The example shows how the engine could merge neighbouring cells and the resulting xls document. To conclude this advice: align components where it is possible.
Another peculiarity of the matrix is less obvious but still important for reports that will be printed. In some cases, a report is exported to xls to be edited it and then printed. On the picture a
report with misaligned components is shown. It can be noticed, that this report contains many superfluous cells within the matrix. The matrix avoids this by aligning components if their borders’ positions don’t differ noticeably from each other. After the alignment is done, the report will become like on this picture. In some cases, the alignment shrinks a report, in other cases it enlarges
it. If a report is built so, that its components occupy all the free space in a print page, it can so happen, that the aligned report will not fit into the page and have to be printed on several pages instead of one. If the report wasn’t aligned, it could turn out that the number of columns in the matrix is so big, that it exceeds the maximum possible value for a target format (e.g. xls allows up to 255 columns) and the “superflous” columns will not appear to a file at all. The solution is simple: don’t make reports that occupy all the free space in a print page.
The next feature is rather evident, but not everyone knows it. Against graphical formats wherein a picture is defined accurate within a pixel or a millimeter, a document in a textual format is defined via
more or less complete description. Let’s assume you have an rtf document which contains a cell with left-aligned text inside it. What will be the offset from the left border ? This parameter is in greater degree dependent on a program that you will use to open the document. If you opened it with WordPad, you will realize that the offset is, for an example, 0.5 millimeter, but if you pened the same document in OpenOffice, you will realize that the offset will become 0.75 millimeters. There is a vast of similar parameters that are completely out of control by the document’s description, and defined in some way by a program viewing it. Most of them don’t have an effect on the appearance of the document, or do have an effect but so tenuous that a man can hardly see it. But there are several parameters that can significantly change a view of the document and make it unreadable. One of these parameters is linespacing. FR Designer allows you to set it, but not all formats you can use for exporting supports linespacing. For an example, if you designed a report that contains a text field with small linespacing value, and then you exported it to xls that doesn’t allow to set linespacing and get a document as on the picture. MS Excel drew a text in the cell with bigger linespacing value than we expected. As a result, a part of text in the cell overran the bottom border.
Another advice is not applicable to all formats, but at least, it is for xls. If you made a report with a picture as its background, after exporting to xls it can turn out that text originally placed in front of the picture, was moved back and hidden by the picture.
Contrary to table formats, where data is infexibly anchored to cells, pdf files allow to set nearly any placement of textual and graphical elements. This means that the pdf export engine does not need to transform a report into a matrix, that’s why it does not have restrictions for reports that are designed to be exported to a table format. This also means that the possibility to set almost any design of a report leads to obligation of the pdf export engine to specify all elements in the report in detail. The necessity to specify these details makes the engine more complex. That’s why many elements within a report’s design that are very rare in real report but require complex implementation in the engine, are transformed into pictures and inserted into a pdf file. This simplifies the engine and makes most reports exported correctly, but also increases file size and leads to other undesirable effects for particularly taken reports. The common advice applicable in all cases is to use a minimum set of design techniques enough to make an expected view of a report. Here are a few special recommendations:
Do not use text formatting if it’s not needed in a design. Complicated text formatting, either rtf or html, will make the pdf export engine transform the text cell into a picture. If the text occurs rarely, it’s not critical, but if the text is everywhere in a big report, then the size of the generated file can significantly increase.
Clipping & WordWrap
These two options, set to values different from their default state, may lead to replacement of text with a picture. This is explained by the fact, that these options can
require unusual ordering of words.
Use only standard fonts if the desing of a report allows this. If you create a pdf document from a report with rare fonts, it can happen that a system in the pdf file which is to be opened, do not have these fonts. If the fonts will be embedded, then the document size may significantly increase.