DmitryV:
Due to our customer's suggestion, I have implemented another approach on how the tables are build. Namely, they suggested using cell paddings instead of paragraph indents and spacing (earlier I rejected that idea because I couldn't achieve correct table layout when paddings differed from cell to cell, but that is the past) and setting line spacing to single. Sorry for a bunch of technical details; please find attached. You're going to see page contents have become shorter, thus minimizing the chance of expanding off the page somewhere in the document. Now I'm worrying about whether the contents look shorter than needed... please give your estimation :)
I checked your attached document, and I think that while now it has no black pages as it used before, well, it IS actually too short. There is a lot of wasted space at the end of each page, so much that actually that specific document could be 2 pages long instead of 3. I'll need to try this new feature with other reports to have a correct idea of the results we can obtain. But, could it be possible to specify an option of what rendering method (old one VS this new one) to use?
I started sorting out the margins issue. I have implemented the following algorithm. Page margins are considered to be Word's default (1 inch) unless report elements are located closer to page edge; in this case the corresponding margins are reduced appropriately. I think it's okay for the time being. Introducing a special parameter to set the margins explicitly is still to come.
I'd say this is a good starting point, waiting for the final implementation of the parametric margins :)
So please find attached. This week is going to be hard :) Apart of keeping on working with you on the persisting issues, I want to finish working on the margins, implement the PAGE field support, (maybe) introduce the 3-state option for page breaks and (maybe) get rid of EXPORT_LINES and EXPORT_RECTANGLES parameters.
why would you want to remove the EXPORT_LINES and EXPORT_RECTANGLES parameters? I think they're quite useful, and as a matter of fact we are using them in our print servlets :)
By what you say it'll really be a tough week. I'm at your disposal for every test you may be wanting me to do for you. Since you haven't started implementing the page numbering yet, may I ask you if can you implement it so to recognize strings in different languages? For example, "page X of Y" for English, "pagina X di Y" for Italian, and so on for other languages. I think it'd be useful for your international customers!
By the way, it seems like 0_1 contains overlapping items. When
debugging, I sometimes encountered empty text elements whose
coordinates and size exactly matched some others. That led to the small
(1.0 pt) paragraph breaks that follow some of the text in table cells,
see them? I'm wondering if I'm correct. Could you please double check
it in your design? If I am wrong, then this is an issue on my end, but
that only happens for 0_1, that's what is odd.
that is correct, that document has perfectly overlapping elements, with a "print when" statement so that only one of them is printed at each time. Such constructs are present in other reports we created, and has presented no issue to us up to now. I mean, all other document with that kind of overlapping elements, but making so that only one element is actually printed, has given us no problem with your library.
And finally, please try out an interim build I'm attaching. I'm looking forward to your response :)
do you want me to generate again our big document?
BTW, this week our company is going to close for vacations, from August the 7th to August the 17th, just to let you know ;)
I’ve just fixed that. I’m going to provide you another hotfix that always preserves cell height very soon.
Please expect getting rid of the rest of issues shortly!