This request is due to a "conceptional" bug in txt reports.
We use 14 and 7 pixels as character height and width. We dont use any float numbers, since this way, it is much more easy to design a txt report. Each element's height/top/width/left attributes are coefficient of these numbers, so that we get WYSIWYG experience for txt reports. (There are lots of roundings in txt exporter, sometimes it is hard to get it to work in the way you want)
Here comes the problem: The filling!
Even though everything looks fine in this way, you need to use single line text boxes everywhere. In filling process, height/width of elements are calculated with the font info which is actually useless in txt reports.
Lets say, if a height of an element is calculated as 8 pixels (with the given font info), its rowspan is round(8/14)=1. So we dont see any problem in the report.
However, if a text element is using some text which is multiple lines, probably one or more lines will be cropped depends on its length (line count etc)
In the filling process, we dont know if it will be exported as txt or some other format.
The problem is, there is no genuine way to correct the format in current scenario. Whatever font info you use, it is hard to get exactly 14 pixels for a single character height.
Instead of such a method, maybe simply we could give an optional virtual font info which includes charcter widht/height to the filler.