ceday

Basicly encapsulating coordinates (rendered x,y offset and length/witdh) as another object, lets say "coordinates", using it as Optional. If it is calculated in the first run, dont let it change in the next ones. (print when expression should be Optional too) So in this way, in the "runtime", its does not matter how many times you try to render a band, if it doesnt fit for a "new page", it wont forever. iterations should not change rendered band height, i think this is acepptable. But in order this to work, in the new page, reprintable elements (ex: elements in page header), should have the same boolean value for print when expression, so in each iteration with a new page, available height might not change. But print when expression might change due to change in page variable. I always thought this was the problem, i cant think of any other problem to prevent to solve this issue. And it is not easy to come up with a good solution for this :) Lets skip to new idea then, maybe not a good solution :) (which we have implemented but not exactly as the below,) While in band filling process, JRPrintBand.elements.where(not printed because of "reprint").size() == 0, (this is a control whether we actually consume any element in the filling process) increment an overflow count and break process if it is greater than given max count. Some people suggested to implement max blank page, I think this is actually what they want :)

I dont get why this cant be recovered from. If a subreport or a band doesnt fit with given available height and doesnt break, it will not be fitted in the next runs with same or less available height "as long as anything is changed because of some print when expression". The height of generated band/subreport wont change since they will be exactly generated as the first one. (assuming any element printed in the first run, will be printed in the next ones; data may change but it wont strech beyond first run) Edit:Well it might stretch to higher value, because of written a pagecount variable text, maybe treating elements as same as "later" evaluations in the next runs, doesnt allow them to stretch more than first run. I am really stuck at pagecount variables, right :) I dont know what i am missing here :)

Hi Teodor, While this one is a promosing future, I have another proposal, which you might not like in the first sight :), since its a breaking change, but keep an open mind :) AFAIK, infinite loop checks can not be done because of "pagecount" dependent variables. Do we really need them on elements? or do we really need them at all? I think it would be just better to let them in "band expressions" but with a fixed number, not an expression (lets say page=0) In this way, while consuming any element to process, if you add a new page, you will know how to check if something is going wrong. Most people using it for some initial header on page=0, since there is no way to do it in any other way right now. (it would be good to define a band before column/group headers btw, actually this is a must for this proposal :)) Except this one, some data should be written if the pagecount is greater than 5? This doesnt make sense. While it seems you strip some given features away, you do not really. (btw, i think you cant do much about report classes but imo it can be ignored as a wrong usage) In the long run, this would make engine better and faster Give a thought about it :) Edit: come to think of it, there could be some scenarios, you might need them. Lets say, you want to export a report max page 10, or mininal pages to 10. you have somedata1, somedata2. If you exceed 10 pages, you want to exclude somedata2 from report. So maybe, allowing pagecount expressions as is in "band expresions" would be enough for this. New idea: Introduce a new global property, if a "print when expression" is evaluated, it will not be again, if the page breaks or something.. So if its evaluated, its done :) Or, dont introduce this property, I think this should be the default behaviour :)

probably this isnt a proper solution, but it works. try to override logical fonts with physical ones in font extensions, then you will get what you expect :)

a simple example template attached.

JR doesnt do what you need. It is a reporting tool. However, you can use itext (JR has it) or someother library to do that. There are lots of examples.

see attachments for basic sample.

lets say, you have two fields, one for label (fixed length/height), the other one is actual data. put them in a frame, use "strecth with overflow" with data field. then for the label field, for stretch option, select "tallest object in the band". (altough it says band, it actually gets the tallest object in the frame, which is the container) also, if you have other elements below them, you need to make their position type as "float"

anonymous:anonymous

trunk doesnt include some changes made in 4.0.2 version. (JRParagraph interface and related changed) is that normal? I was updating JR version, since I saw couples bugs fixed in SVN (introduced in 4.0.2 version), I used "trunk" codes. Is it possible to get the latest code, somewhere ? :) Post Edited by ceday at 07/11/2011 13:56

I guess handling this bug appropriately is kind of hard :) I will modify the code and add a "overflow iteration max count" check. It looks much better than seeing "out of memory" :) I hope this will be fixed one way or the other in official release.

I guess the problem is you cant be sure next generated band height will be the same because of existing some scripts (ex:printWhenExpression using pageCount variables etc) So there is always a probability, it might fit in the next generation. a)a flag could be used if there is a such an expression in the band. b)user optional flag to ignore such differences. (to throw an exception) maybe a & b should be used together if possible. also server got out of memory error today, even without using subreports. there is also a problem with page break element.

I have encountered this problem in one of our test servers, the app was down because of out of memory error. It might be a deadly error for production environment. I think I understand how the problem occurs, but I didnt get the part why it cant be fixed. lets assume, there is an internal variable (previous available space before running subreport), and when it overflows, if the current and previous available spaces are same, it is obvious it wont fit again, and an exception should be thrown. Also passing master page sizes into subreport internally, would be useful to check. If the generated subreport size is more than master page sizes, it wont fit obviously and an exception should be thrown. Do I miss something?

net.sf.jasperreports.text.truncate.at.char=true this is the only setting you should change for what you need. it works fine for me.

-Use scriptlet -Declare a variable and assign its value with each record. Compare the data with the variable (which is previous one) But your data should be sorted.