Servlet build error using Aspose.Words for JasperReports

We have followed your advices, removing the background image and the one in the header, but we still find some difficulties in obtaining a decent print of our header (I mean, we’re focusing on it for now, but we do not exclude there will be more difficulties with other critical points).


The header, as you’ve seen, is organised as some sort of table. We have modified it removing the overlapping image and all the overlapping lines and rectangle, which print we have disabled. But still, the table generated by the library is unprecise, even if all elements in the header are perfectly alligned at the level of pixel-precision. As you can see in the attachment, somehow some border are missing, even if all borders are set to be printed.

Why does this happens? Is a template design error, or is it due to a library error?

Thank you for your attempts. I will look into the issue right away.

I'm going to fix the borders problem in a few hours. The release of Aspose.Words for JasperReports supporting headers/footers will also be ready very soon.

Meanwhile, I would like to ask you for a suggestion.

It is clear that the pageHeader and pageFooter bands should become headers and footers in a Word document, but what about title and lastPageFooter? They both present in your report, that's why I'm asking. I presume they should stay on the body level because they are not "full-scale" headers/footers actually.

Thanks.

DmitryV:
It is clear that the pageHeader and pageFooter bands should become headers and footers in a Word document, but what about title and lastPageFooter? They both present in your report, that's why I'm asking. I presume they should stay on the body level because they are not "full-scale" headers/footers actually.

I'd say that your interpretation is correct. Personally, since the title is something to be put only on the top of the first page of the report (or subreport) and similarly the lastPageFooter is something to be put only on the bottom of the last page, I'd say it is correct to print them only once inside the body of the document itself.

The same is true, in my opinion, when it comes to groupHeader and groupFooter, I think that they too should be simply put in the document body, since they're usually used to print tables and placing them in a different position would completely screw up the table.

I really hope that the fixed release will be available soon, since we need to start using it as soon as possible. If all goes well, we plan on buying the OEM licence for it (together with the Aspose.Words for Java license) during the first days of august.

If you need more print examples, template or .jrprint files, please let me know.

Thank you for your suggestion. The hotfix is going to be available in 1-2 days. It is almost ready actually.

I decided to deliver you from further waiting and provide the current build of the product. Please find attached build along with a document it currently produces. As you can see, it looks good now. Note I have set the SpacingFactor parameter to 0.95 to avoid shifting the content off the page. You may want to play with this parameter's value for other reports.

Report's locale should also be supported by this build. Please try it out and let me know what problems still persist.

Thanks.

It is not a problem for us to wait a couple of days. Actually, we’d rather prefer it, if this means to be sure to obtain a fully working version of the library we need so much.


I’m going to try the new version right away!

Thanks for all your efforts!

EDIT: how do we set a report’s locale? Is it a method of your library or is it a property of the report template?

EDIT2: also, how do I set the spacingFactor parameter you speak about? I’ve tried a print of a report with the new library without changing it, and the header was completely messed up, part in the header section and part in the body section, so I guess I really need to set this correctly, but I seem to be unable to find it in the last iReport

I’m attaching an example (actual print + template + .jrprint) of what we now obtain if we try to print our reports with the new version of Aspose.Words for JasperReports. As you can see the header (which we have redraw to make it simpler) is completely screwed up.

Thank you. I'm working on this problem right at the moment.

Regarding setting the report parameters - are you using JasperReports or JasperServer to generate Word documents?

DmitryV:
Regarding setting the report parameters - are you using JasperReports or JasperServer to generate Word documents?

We are using JasperReports.

I've found the SPACING_FACTOR parameter in the documentation of the library, so we tried to set it lower (up to now, I could only try 0.95 because the available time for testing is limited for me, but I'm gonna try 0.9 and down as well) but the header is still as you see in the example.

EDIT: I would like to point out a strange fact: if I try to print different reports that use the same header, the header itself is still completely messed up, but often in a different way from one report to another. I've also tried bringing the spacing factor down to 0.75 using the class parameter, but still no result, I'd say it wouldn't help.

It shouldn't be that messed up anymore :) Please try out the attached build. The problem had to do with the fact you have one or more subreports in your header.

Please let me know what else is still wrong.

Thanks.

The header seems now correct, but there is a problem in reports longer than a single page. I’ve attached an example of what I mean.

Thanks. It seems like your reports usually contain a number of subreports that basically causes difficulties with report items origin detection. However, I’m going to fix this right away.

Well, yes, our reports do have a great number of subreports indeed. Some of the most complicated ones can have 40 or more subreports, with a depth of nesting of about 4 or 5 levels, but the one I attached you is a very simple one, made of just 3 subreports.


We could say that we’re doing a great job in stress-testing your library :smiley:

I wanted to point out a lack of coherence I noticed in Aspose.Words for JasperReports library, and I didn’t feel like opening a new thread, I think I’m already flooding you enough.


Anyway I’ve attached an example of the print of two reports. They’re almost identical, as you can see by checking the template, but one is printed using a table layout, the other one is print correctly as simple text in the body document. Why does this happens? I mean, why are the two templates interpreted differently?

EDIT: attached another document that gets printed correctly.

It seems like we are lucky indeed in having you interested in the product, because it's a real stress-testing and thanks to you the product has been greatly improved in last few days :) So - voila - welcome another intermediate hotfix specially for you, which as you can see handles your latest reports as expected. The excessive tables issue was fixed, too :)

As usual, just let me know if there are more things to fix.

Thanks.

Thank you! I’ll try the new build right away. By the way, I’ve read in some other thread that you should be releasing soon Aspose.Words for JasperReports v1.2.0, but when precisely should it be released?

So… We have done a great deal of new tests, and I’m attaching two archives:


- report_1_7.zip, which contains a simple document created with a simple report (only 4 subreports). It should contain 2 images but the first one is completely messed up. This never happened before, in all the print I tried to do

- DVR_3_3.rar contains a huge, final document, which is about 180 pages long. I have put many comments in it (in bold red) of things that, in my opinion, should be corrected, though I cannot really tell if they CAN be corrected :slight_smile:
This document was created by printing all the 74 reports our application creates and then they’ve been merged in a single document using the Aspose.Words for Java library (which we are probably going to buy as well), following a similar technique we have used before for “simple” .rtf reports.
Since there isn’t a single .jrprint for the whole document, I’ve put inside all the single .jrprint files of the single reports.

It’d be interesting to know if the defect we can see in this two documents are our fault (bad report design) or is it a problem with the library.

I like your comments throughout the huge document :)

I'm working on them right at the moment. For now, I can say that everywhere you have mentioned the "blank page" problem - the answer is, reduce spacing factor. Those are page (section) breaks pushed off the page due to too long content. This is inevitable in flow mode because we cannot position document items, we only place them one after another and set their heights. Borders and other things may occassionally lead to the fact that the overall height exceeds what expected and we have a page break on the next page. So - as a workaround - play with the SPACING_FACTOR parameter until you have all contents fit their pages. That's the best we can do at the moment.

As to report_1_7, while I couldn't reproduce the problem fully (because the images were missing), I think I have fixed it. There was excessive spacing before page footer that I now removed.

Expect the news tomorrow. I'm going to release 1.2.0 officially on Moday (answering your question), but you shouldn't care of that much because you've been always provided with the latest codebase :)

DmitryV:
I like your comments throughout the huge document :)

I hope they were useful to you! ;)

I'm working on them right at the moment. For now, I can say that everywhere you have mentioned the "blank page" problem - the answer is, reduce spacing factor. Those are page (section) breaks pushed off the page due to too long content. This is inevitable in flow mode because we cannot position document items, we only place them one after another and set their heights. Borders and other things may occassionally lead to the fact that the overall height exceeds what expected and we have a page break on the next page. So - as a workaround - play with the SPACING_FACTOR parameter until you have all contents fit their pages. That's the best we can do at the moment.

Ok, I'll try to "play" a little with the spacing factor to see if I can remove those annoying blank pages.

Anyway, I'd like to ask you what I think is quite a technical question: why do you build up the document putting "manual" page breaks? Shouldn't Word be able to organize the pages by itself? That would avoid the blank pages, I think.

As to report_1_7, while I couldn't reproduce the problem fully (because the images were missing), I think I have fixed it. There was excessive spacing before page footer that I now removed.

I have attached the two images, if they can be of any use for you.

Expect the news tomorrow. I'm going to release 1.2.0 officially on Moday (answering your question), but you shouldn't care of that much because you've been always provided with the latest codebase :)

Oh, I know that you always supplied us with the latest build, and for that we are thankful :) it seems we are your official beta testers right now :D

I'm eagerly waiting for the new version to perform new tests. And while I'm replying to you, I'd like to add another question: would it be possible, using this library, to obtain a way for correct page numbering? I mean, with self updating fields like Word would do? If you notice, in our big document, if you remove a page or add a new one, the page numbers in the header become totally wrong.