Well, it seems to be a good idea to provide an option to disable explicit page breaks. The point is that, in this case, if you have designed something to be at the beginning of a page, don't be surprised if you occassionally encounter it on the previous page :) This is a tradeoff of page breaks being missing.
Another con is the fact that if you headers or footers differ throughout the document - you'll lost the difference as to have it, you should place headers/footers in different sections of the document.
And yep, I was going to implement a recognition of at least the "Page X of Y" text to replace it with Word fields so that page number would be updated automatically.
But please let's release 1.2.0 first to make our customers happy with headers/footers - and the above two features will be surely included in 1.2.1 then :)
A Word document consists of one or more sections. One section may only have one set of headers/footers. If you want to have different headers and footers throughout the document, you need to place each one to a separate section. So you basically need to have one section per page. And therefore there are no page breaks, there are section breaks actually. Which, marked as "start new section from new page", serve as page breaks, too.
If I'm still not clear enough, just let me know :)
Oh, I understand now! Thanks for the clear explanation! 
Uhm, actually, if you’d be able to implement the correct page numbering (via the identification of a particular string as you were saying before), it’d be much better to have a single section (with a single header/footer) throughout the whole document instead of a different section on each page. In fact this would make the document easier to modify, with the header/footer with the page number auto-adapting themselves, while now every header/footer is not linked to the previous or the next one, and we would have to link them by hand using the option inside Word.
I can link them programmatically if it simplifies the process on the current stage.
Could you please send me a .jrxml for 2_2? It has some strange design I can't handle :)
Besides, could you please specify what .jrprint contains the many-little-rows-table problem? It’s a real hassle finding it amongst the numerous prints
DmitryV:
I can link them programmatically if it simplifies the process on the current stage.
I think It would simplify it, but only if/when the implementation of the sequential page numbering will be completed, unless I have misunderstood what you mean.
Could you please send me a .jrxml for 2_2? It has some strange design I can’t handle
Here you go!
Besides, could you please specify what .jrprint contains the many-little-rows-table problem? It’s a real hassle finding it amongst the numerous prints
That’s kind of a problem, I know. Sadly, “Sez X” “Doc Y” doesn’t necessarily corresponds to jrprint X_Y… and that particular report is really complicated! Anyway I have attached it as an archive for you.
Yes, that's what I meant actually.
I think I'll release 1.2.0 now as is (because lots of things have been added) and then get back to fixing the issues.
DmitryV:
A Word document consists of one or more sections. One section may only have one set of headers/footers. If you want to have different headers and footers throughout the document, you need to place each one to a separate section. So you basically need to have one section per page. And therefore there are no page breaks, there are section breaks actually. Which, marked as "start new section from new page", serve as page breaks, too.
A question that just popped in my mind: do you use only section breaks as page breaks? What if someone needs to start a new page without changing section?
Mmm… why would they need that? But basically I can implement a three-state option for page breaks: SECTION_BREAKS, PAGE_BREAKS, and NONE. Would that be okay?
I do not actually know if there is a practical reason for this, I was just wondering. The first reason that came to my mind, was to preserve the link between the page header on the various pages, instead of breaking those links.
Imagine, for example, a document which is structured in 3 section, which we may call INTRO, CONTENT and OUTRO. Each section has its different header. So, if I need to add a new page in the INTRO section, I want that page to belong to that section, and therefore have its header. But that would require me to insert a simple page break, not a section break on new page.
Obviously, this is all academic debating. I mean, for our own application, I do not think we’d need this feature (even if the three-state break flag would be nice), but I think it may come useful to other of your customers the difficulty I can see here is the fact that you cannot just set the type of break at compile time, it should be dinamic so to recognize what the user really wants to achive, and I do not know if this can actually be done with JasperReports. For what I’ve seen, it supports two kinds of break, namely “page break” and “column break”. Perhaps you could interpret the column break as a simple page break, and the “real” page break as a section break, but I’m not sure this would be something correct to be done.
Anyway do not know where all this speculation could lead us…
It will lead us to a better product for sure ;) I have just thanked you in the release announcement of 1.2.0 because this is you who let us include lots of enhancements into it.
I think I will stick with the three-state option idea for the time being, and we can accomodate it to the customer needs in the future. Customer-driven development is our key principle, you should have probably noticed that :)
The page margins is a known and unfortunately unresolved problem. The point is that the JasperReports print model conveys no information about page margins at all... I still hope I have missed something and keep investigating the library, but it seems like in vain.
So we do not "reproduce" the margins. We set carriage returns and paragraph indents to position report items. That means they already include top and left page margins into their X and Y coordinates. We could try to deduct them, but right and bottom margins will be anyway unresolved.
We requested JasperReports developers to include page margins into future versions of JasperReports, but they didn't reply so far. I was pondering on some workarounds like making the user specify margins via report parameters, but it seems awkward to me.
So that's where we are stuck at the moment.
With regards to report_2_2 - I think I will sort it out and provide you with another build of the product in 1-2 days.
Thanks.
I understand the problem, yet it seems very strange that JasperReports print model carries no information about the page margin :S I mean, if I remember it well, documents created with “plain” JasperReports do have page margins (but I might be mistaking here).
The problem in not having page margins is that if you try to copy-and-paste the content of a document generated with you library to a normal document created by Word, it’ll be quite a mess. For me personally, being myself a programmer, I agree with you when you say that it’d be awkward to set the margins as a parameter inside the library, but still, it’d be better than no margin at all, wouldn’t it?
Documents created by the standard RTF exporter consist of absolutely positioned items, so the margins there make no sense and are simply default Word margins (1 inch or so, don't rememeber exactly). In our case, we have to know margins precisely as we have to subtract them from report items coordinates.
I think you are correct. We can enable users set the margins themselves via the parameters. Unless set explicitly, the margins can have say the default Word values (1 inch?) and that's what we will subtract from the coordinates. Alright?
DmitryV:
Documents created by the standard RTF exporter consist of absolutely positioned items, so the margins there make no sense and are simply default Word margins (1 inch or so, don’t rememeber exactly). In our case, we have to know margins precisely as we have to subtract them from report items coordinates.
Right! That’s why I remember seeing margins in RTF documents generated using JasperReports, they were just the default margins!
I think you are correct. We can enable users set the margins themselves via the parameters. Unless set explicitly, the margins can have say the default Word values (1 inch?) and that’s what we will subtract from the coordinates. Alright?
For me it is alright I’d like to give you one recommendation: I think you should enable the user to choose whether to use inches or centimeters in setting the margins. This is because here in Italy (just to make an example) we use the International Measure System (not sure the name is correct, though, I’ve always seen it as “SI”), which is based on meters, and it would be very counter-intuitive for us to reason in inches.
Okay, maybe it is even worth making it accept a string like "1in" or "2cm" like Word UI does.
Anyway, I'm quite disappointed on the fact they treat page margins such minor feature that it doesn't deserve being included into the print model...
The JasperReports exporters don’t manage them as no one of the built-in export formats actually requires page margins. As I mentioned above, the coordinates of report items simply include left and top page margins. Things change when it comes to flow layout Word documents