This has already been posted in the general section, but somehow it got wiped under the (message-) table:
We use OIPI to convert reports to PDF. Generally speaking, it works fast and well, if the reports are based on single value tables.
However, when using extensive text columns in many of the records the process of output conversion to PDF becomes very slow.
This seems to be the basic problem:
When there is a large multivalue or textvalue content in a report column, i.e. a field content that doesn't fit on 1 page (within the predefined dimensions of the page layout), some sort of page overflow triggers heavy additional processing; to recalculate the graphical output I assume.
This seems to apply not only to PDF output, but other variable length formats, like RTF, as well.
On reports, where the record content fits on 1 page, this doesn't ocurr.
Any suggestions are welcome.
- Wilhelm -
You can always call Get_Printer("POS") after each line to determine where you are on your page. It usually means splitting up you extra long field to print it incramentally.
Pascal
Pascal,
we print record-wise (not on a line by line basis).
This is very flexible (fonts, images, page layout etc.) and fast, provided the record doesn't exceed a page - but extremely slow when multipage records have to be recalculated.
If we did line by line check, I guess, that we would have to apply the same time consuming calculations, which doesn't seem very efficient.
Regards
Wilhelm
Wilhelm,
we print record-wise (not on a line by line basis)
Isn't there a useful level inbetween the two extremes of records and lines?
The layouts that my apps print can all be described as table-like structures. There can be tables within tables, but the main structure can always be described as a table consisting of rows.
The simplest possible row is a rectangular block of text, with the content of one field, e.g, a long text field.
The next simplest row is a row of cells, each with the content of one field, or an image.
There can be more complex rows, but in practice I can manage with rows having cells that aren't more complex than a simple column of cells. And I find that symbolics with values from several fields often can replace complex layout.
In OI and OIPI there are programmatic tools to calculate how high a certain text will become when displayed/printed within certain rectangular limits (Utility TEXTRECT and similar in OIPI). So it's easy to calculate if such rows as described above will fit on the page. I din't think it too time-consuming either (but others can tell you more about that).
If a row doesn't fit on the page one might take one of two possible actions:
- Move the whole row to the next page
- Split the row.
Moving a row to the next page can be a good idea if there isn't much room left on the current page, or if the row isn't very high. Also some rows will not look good if split across two pages.
When splitting a row one needs to do more time-consuming calculations. I don't think there is a programmatic tool that can tell you how much of a text will fit within certain limits. I think one must/can use a sort of binary trial and error process to find the character position for the split.
But splitting might not occur too frequently if the layout is designed with a stress on rows.
- Oystein -
Oystein,
thanks for your comments.
If a row doesn't fit on the page one might take one of two possible actions: - Move the whole row to the next page - Split the row.
In most cases, the row can be handled to fit within the page size. Since we also keep complete documents (with 1 up to n pages)within a single field splitting becomes complicated - and as you stated - calculations get time-consuming, especially with variable fonts and text justification.
I guess, we first concentrate on the basic reports, which have no problem at all and post again later on - with more detaills on this problem.
Regards
Wilhelm