But doesn’t JasperReports exports in ODT also? Or am I confusing it with your library? I mean, unless you export in ODT like you’d do in RTF, with positioned items, you would certainly need page margins, wouldn’t you?
I don't think so. Judging by their code, they don't set page margins, either (although I didn't play with generated ODT documents). Why would you need page margins in this case? They can be, again, zero or Word's default.
Well, I thought you’d need them in that case because I thought that ODT used flow-layout instead of positioned elements. Perhaps this is my mistake 
Okay, just tried to export a report to ODT - all the margins are zero, as expected. Alas.
No, it’s not a must. We are currently having them zero as well and it works, doesn’t it? 
It works indeed! I was just thinking from the perspective of the “common” user, like one of our customers could be and I think they’d be quite bewildered by this no-margin layout.
Okay, so let’s stick with the parameters idea. Expect it in the next hotfix
Ok, I’ll be waiting. In the time being, I’ve reviewed all our report templates (over a hundred reports each with a dozen of subreports… I’m starting to hate iReport) to make them easier to render to your library. Results now are quite good, with just a few issue to solve (like the (in)famous blank pages), and I’ll do some test to solve them too, like trying to change the spacing factor to see what happens.
After some more tests I’ve noticed a strange (and unwanted) behaviour: some characters seems to not be correctly recognized.
I’m attaching an archive containing a document example, with its jrprint and document template as usual. If you open it, you’ll notice some characters being replaced by little squares. Why does this happens?
No, I can't see them neither in the archived document nor in the document produced from the .jrprint.
Could you please specify where they are?
Since this never happened before, maybe something has changed on your machine??
For example I see one of those squares at the beginning of line 31 and another one on line 46. But actually we just found out that this is due to our own application encoding, so it is not due to your library, at least for what we can tell. We still have to understand why the PDF comes printed correctly, though…
Mmm, then I don't know how to reproduce that :)
Regarding 2_2, sorry for misleading, I actually needed 2_0 to get rid of excessive page breaks in the header. So by the moment we have three points to resolve:
- You asked me about the progress on 2_2, isn't it because you noticed something incorrect in the resulting document?
- Please attach a .jrxml for 2_0.
- I'm still looking for a .jrprint that causes empty tables with thin rows to appear :) there's a chance I have already fixed that when got rid of excessive tables (remember that issue?), so maybe that's why I can't find it :)
DmitryV:
You asked me about the progress on 2_2, isn't it because you noticed something incorrect in the resulting document?
There is nothing incorrect, but as you can notice, it is really table-heavy, so I was wondering if there is a way to make it look better... but perhaps that's something which can be solved only on our side :)
Please attach a .jrxml for 2_0.
I'll do more than that, 'cause a strange problem occurred to us right now: whenever we export one of our *_0 reports, some of them are empty, just header and footer, but this happens only for .doc/.docx export!
I'm really confused... I'm attaching you three archives, one contains the doc version, one the pdf version, and one the odt version (created using your library). Each archive contains its own .jrprint (and the doc version contains the template also), and each report was printed using the same parameters and data given to the report. As you can see we have obtained different results, and I cannot understand how this is possible. Perhaps you can help me?
EDIT: SOLVED! It was an error in our own templates, but still I'd like to understand why the odt version got printed correctly, but not the doc version.
I'm still looking for a .jrprint that causes empty tables with thin rows to appear :) there's a chance I have already fixed that when got rid of excessive tables (remember that issue?), so maybe that's why I can't find it :)
You can give a look to jrprint 6_11 in the "DVR" archive, which contains an example of it (matches "Sez 10" "Doc 2"). I just tried to print it again, and actually those mini-tables are gone, so one less problem! :)
Since the 2_2 issue is not critical, let's postpone it for a better time :) we'll get back to it after we have the remaining problems sorted out.
The *_0 reports have such design that is not correctly handled by the library at the moment, and that's why I asked you to provide one of them. Thanks for that. Why the ODT version differs - still unclear to me, and I'm going to investigate all of the remaining issues immediately.
Solved? Have you changed the design? Is the .jrprint still up-to-date?
Yes, the design was changed to correct the problem of the empty report. Now it prints the report correctly, for what I can see. Here is the updated archive.
Okay, now I see why it looked odd to me :) I'm glad now it is exported well.
So - we should have almost all issues solved by this time, shouldn't we? Of course, the one persisting is the legendary "page contents expands off the page". But please wait a bit, another user has suggested changing the way tables are built. It has to do with line spacing and cell paddings and it should reduce the number of blank pages without the need to play with SpacingFactor value. Once I rework the approach (which shouldn't take too much), I will attach a built of Aspose.Words for JasperReports here and ask you to generate your huge report again. We will then have a look if we still have something else to fix.
Ok, I’ll be waiting for the new version, and as soon as I have it I’ll generate again the big report for you
In the meantime I want to start some test with the spacing factor parameter, since I haven’t had the time to try it at all.
I’m here again (for your despair) sending you a new archive which I think could help you with the “blank pages” issue, or at least I hope so.
If you open the document in the attached archive, you’ll notice how the distance between the header and the beginning of the body is different from page 1 of 5 to pages 3 and 5 of 5. In pages 3 and 5 there are two extra carriage returns, for a total of three instead of one. Why is there this different behaviour? If there was just one carriage return as expected, shouldn’t the pages be split better?
EDIT: we also discovered that if we disable our footers (for example sending void data to them so that the footer band is completely empty) the page behaviour is much better than the one we get enabling them. So it might be a bad footer management causing much of this issue with wrong paging. Anyway, removing the footer does not remove ALL of the blank pages.
Please do not avoid footers - one of the advantages of Aspose.Words for JasperReports is the correctly supported headers/footers, as you know :) Let me cover all the points so that you understand what's changed etc.
- 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 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.
- Regarding the extra carriage returns issue - could you please make sure other renderers preserve the same (short) distance between the header and the subsequent element on each page?? While debugging the export, I noticed the Y coordinate of the element is smaller on the first page and bigger on the next pages, so I don't think the exporter does a mistake. I'm gonna explore the .jrxml as well, though.
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.