Page 19: The text is outside of the table because there is no reason of enclosing it inro a table. I understand it would be more consistent if the table with an image on the right would continue; maybe this will happen once I implement the "no page breaks mode", but I can't promise.
Yes, I know that there is no reason for it to be enclosed in a table, but as you say it'd have looked more consistent with the previous page and the table immediately next =) Anyway this is not an issue at all, but I just preferred to point out everything I noticed in the print result, instead of risking not to report something which might have been important. Actually I'm quite sure that once you'll implement the no-page-break mode it WILL continue inside the table because, if I do not mistake, that's just the way Word works.
Table alignment here and onwards was fixed.
Page 28: The too big cell was fixed. The grey separators were fixed too.
Glad to hear this! Section 2_2 was really messed up.
Page 42: Not sure what waste space you mean.
Now that there is no need to rush, I'm going to continue tomorow :) Have a good vacation and I'm looking forward to see you after the 17th :)
When I said about wasted space, I just meant that in that specific print, the next part, the one beginning with "Argano" on page 43 could actually fit on page 42, and there'd still be some space left. But this too is really not an issue for us =) as I said in the note, I'd rather have this instead of a page so full oftext that it overflows!
I already said it, but I'd like to repeat it once more. Good job man!
WHOOPS! I didn’t think about looking in the download page! Sorry, my fault. But I’ve read the realease notes and it doesn’t seem to contain some of the feature we talked about… Or is it just me not seeing them?
Welcome back! Indeed, I didn’t manage to publish a major release yet mostly because I have other projects to work on. 1.2.1 should address most of your issues, however. As to the features to come - I have already implemented setting page margins and page breaks type, but got stuck at building the page numbering recognition. The main reason is that the text to find and replace (such as Page X of Y) is often spread between two text elements, like in your report, and is eventually placed into two adjoining table cells. The recognition module should be smart enough to properly handle this situation, as well as others. So that’s why 1.3.0 is not out as of yet. But stay tuned, most of the work is done. And, as usual, I can send you the latest interim build because, as I remember, setting page margins is a more important feature for you, isn’t it?
Speaking about page numbering recognition, I think you do not need to make it that clever to recognize the text to be replaced if it is spread in two or more text elements: why would someone need to spread it in such way? In our reports, it is done that way only because of how JasperReports works.
The only thing you might want to do, in my opinion, is to try to recognize if there is some “style” tag in between, but even this could be more than enough. I mean, it could just be a requisite of this feature to have the text to be replaced all within a single text cell without any tag in between, couldn’t it?
This way I think it’d be much easier to recognize such text. The only thing I’d add, as I already suggested, is to allow users to replace also text in different languages, like the Italian “pagina XXX of YYY”.
As for the rest of the feature, yes, it’d be very useful for us to have an interim build so that I can try them ASAP, thanks =)
I'm not sure I understood what you suggested. Imagine I'm looking for the "Page X of Y" pattern, or whatever user specifies, where X and Y stand for page number and total number of pages, respectively. Now imagine "Page X" is in one table cell and "of Y" is in the subsequent cell. The recognition becomes much harder then.
They are in different table cells because they are in a positioning table where one cell is dedicated for one text element. Maybe I should merge the adjacent cells when I encounter they both contain fragments of the page number text.
It seems that I was unable to explain what I meant, I’m sorry.
What I wanted to say is that splitting the string “Page X of Y” in two cells is just a necessary trick to be used with JasperReports “as is”, so that X is computed for every page and Y is computed only at the end of the report. But, if you just replace the string “Page X of Y” using Word page number fields, you won’t need to split the string anymore: since users wouldn’t need to split it anymore, why would they keep doing it? I’d just keep it simple and make it recognize simple strings, making this a requisite of the feature.
I got your point. However, what you suggest is only feasible for newly created reports or requires redesign of existing ones. I would like to try avoiding that, but not sure if it is worth that from technical point of view. Maybe I should follow your idea. But, for instance, are you ready to redesign all of your reports just for that?
I think that sometime you just have to compromise in order to keep the implementation simple, and I do not think it’d be much of an hassle to make such a simple modification to the template.
Actually, in my specific case, I think I can do it just using a search-and-replace on the xml source of the template, and even if this does not work, manually replacing it would not take long, so I think I could just do it if this means making your work easier… and, to be honest, also to get it done earlier.
Anyway, if you think about it, using your library already has some requisite which are not present in “plain” JasperReports, like the need to avoid overlapping fields, or the fact that we had to completely remove all background image this one requisite, to have the string in a single cell, would be a very small one!
As to the background items - now there is a guard that prevents the code from fail, and soon I'm going to provide a full support for them. Regarding overlapping items - well, avoiding them is not a requirement of the library, but a requirement of the flow layout mode where you just can't place one item over another one :)
Okay, I think I will follow your suggestion and simply implement the recognition of page numbering for the one cell case only. But given that, can't implement detection of a general "Page X or Y" or "Pagine X di Y" phrase? I mean, it is a limitation of JasperReports placing the two variables to different text elements, isn't it? If so, then I may only react if some special pattern exclusive for our product is encountered, just as you suggested.
Matteo, as you know, I'm leaving for vacation until September, 7th. I will stay online and keep watching forums, so we may continue our discussion, but the development will be paused until that moment. Once I'm back, I will release Aspose.Words for JasperReports 1.3.0 with all the discussed functions available, including page number recognition implemented the way you suggested.
Okay, I think I will follow your suggestion and simply implement the recognition of page numbering for the one cell case only. But given that, can't implement detection of a general "Page X or Y" or "Pagine X di Y" phrase? I mean, it is a limitation of JasperReports placing the two variables to different text elements, isn't it? If so, then I may only react if some special pattern exclusive for our product is encountered, just as you suggested.
I'm not sure I've understood what you said here. What about JasperReport limitations? I imagined this feature to be just a pattern matching on a particular string, namely "Page X of Y", and you might search for that string also in other languages like the Italian "Pagina X di Y", but still, it'd be just a simple string, where X and Y are literals, not JasperReports variables (and that's why I'd search for XXX instead of X and YYY instead of Y).
Matteo, as you know, I'm leaving for vacation until September, 7th. I will stay online and keep watching forums, so we may continue our discussion, but the development will be paused until that moment. Once I'm back, I will release Aspose.Words for JasperReports 1.3.0 with all the discussed functions available, including page number recognition implemented the way you suggested.
Are you already on vacation? We were hoping that you could implement this feature and the page margin one before leaving, so that we could release the new print engine.
Yes, that could be a pattern for a simple string like "Page XXX of YYY", but it could also be a regex pattern like "Page \d+ of \d+" to handle standard JasperReports design. But the latter would only be possible if there was no splitting the text into two text elements.
Let me know if I'm still unclear.
I'm already on vacation, but don't worry, I may keep working on AWJR remotely which is not a problem, so I'm planning to provide you with new features ASAP, I hope earlier than the official release is out. We must accomplish this eventually :)
Yes, that could be a pattern for a simple string like "Page XXX of YYY", but it could also be a regex pattern like "Page \d+ of \d+" to handle standard JasperReports design. But the latter would only be possible if there was no splitting the text into two text elements.
Let me know if I'm still unclear.
Ok, I think I got it, but I think it'd just be easier to write the string in a specific way, so that you do not need to use regex... I do not know about you, but I cannot understand them at all =P
I'm already on vacation, but don't worry, I may keep working on AWJR remotely which is not a problem, so I'm planning to provide you with new features ASAP, I hope earlier than the official release is out. We must accomplish this eventually :)
Well, I do not want to make you ruin your vacation with work! I think we might be able to wait that long...
BTW, instead of searching for the entire “Page XXX of YYY” string, why don’t you just search for the words, for example, “CURRENT_PAGE” and “PAGE_COUNT”, and replace the first with the Word field containing the current page, and the second with a Word field containing the total page count?
This way it’d be much easier to find them, even if they’re spread across multiple cells.
Sure, that was great :) I'm currently working on accumulated Aspose.Words and Aspose.Words for Reporting Services issues, but I'll get back to JasperReports very soon. I'm hoping to have our ideas implemented by Monday. And regarding the keywords to search and replace, I have even a more generic but powerful idea. What about providing the ability to export ANY Word field? So the user specifies Page {PAGE} of {NUMPAGES} and gets the same in Word! :) In this manner, you can easily insert a TOC, for example, and other stuff. Of course, you should have the clue regarding Microsoft Word fields, but at least anyone can easily specify page number!
Yes, user would need to now how to actually write Word fields, but it’s not hard to find out how to write them, so I think this would really be the best possible solution.
I’ve noticed you’ve just released version 1.3.0, that’s great! I’m reading the release notes right now, and I’d like to ask you one thing (as if what you’ve done up to now wasn’t enough): would it be possible for you to implement a way to disable the page breaks automatically inserted by your library when processing the template while keeping those explicitly inserted in the template itself?
Sorry for delayed response. Answering your question, try out the PAGE_BREAKS_NONE value for the introduced PAGE_BREAKS parameter. At the moment it simply instructs the renderer avoid putting any page breaks into the document. I'm not sure if Word will automatically concatentate tables that spread over multiple pages in this mode. If you are not satisified with the way it currently happens, let me know.
I'm looking forward to your response with a possible list of persisting problems as usual. I have had an inquiry from another user who reported some weird error introduced by 1.3.0; I'm worrying what that could be because all the tests on my end pass without any issues.
DmitryV:
Page 19: The text is outside of the table because there is no reason of enclosing it inro a table. I understand it would be more consistent if the table with an image on the right would continue; maybe this will happen once I implement the "no page breaks mode", but I can't promise.
this one requisite, to have the string in a single cell, would be a very small one!