DO NOT REPLY [Bug 33801] New: - FOP 0.20.5 AWTRenderer: Sometimes rendering fails in the middle of a table with no error message

2005-03-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 33801] - FOP 0.20.5 AWTRenderer: Sometimes rendering fails in the middle of a table with no error message

2005-03-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: page-breaking strategies and performance

2005-03-02 Thread Chris Bowditch
Jeremias Maerki wrote: Hi Jeremias, I finally have Knuth's Digital Typography and let myself enlighten by his well-written words. In [1] Simon outlined different strategies for page-breaking, obviously closely following the different approaches defined by Knuth. At first glance, I'd say that

Re: page-breaking strategies and performance

2005-03-02 Thread Glen Mazza
--- Chris Bowditch [EMAIL PROTECTED] wrote: As for the plan to implement a new page-breaking mechanism: I've got to do it now. :-) I'm sorry if this may put some pressure on some of you. I'm also not sure if I'm fit already to tackle it, but I've got to do it anyway. Since I don't

DO NOT REPLY [Bug 33801] - FOP 0.20.5 AWTRenderer: Sometimes rendering fails in the middle of a table with no error message

2005-03-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33801. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 33808] New: - problem with large number-rows-spanned

2005-03-02 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33808. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: page-breaking strategies and performance

2005-03-02 Thread Jeremias Maerki
I'd rather not work on HEAD directly because after creating the basics for the new mechanism the whole thing will probably not work for some time (probably 2-4 weeks). But I'd like to be able to check in early so people can review. I expect that the life time of the branch will not exceed 8 weeks.

Re: page-breaking strategies and performance

2005-03-02 Thread Glen Mazza
Just a sanity check here, the XSL specification seems to suggest always the first-fit strategy for page breaking *except* where keeps are explicitly specified. Am I correct here? And, if so, is what you're planning going to result in an algorithm that will help us do this? Thanks, Glen ---

Re: page-breaking strategies and performance

2005-03-02 Thread Jeremias Maerki
Where did you find such a suggestion? I'd be interested to know if there's a hint in this direction in the spec. I thought it was up to the implementation to decide the strategy. I think the way we're now taking in our discussion suggests that we're not going to do a first-fit strategy at all. If

Re: page-breaking strategies and performance

2005-03-02 Thread Glen Mazza
I'm unsure here. My interpretation comes from two places: 1.) Section 4.8, the last paragraph of [1]: The area tree is constrained to satisfy all break conditions imposed. ***Each keep condition must also be satisfied***, except when this would cause a break condition or a stronger keep

Re: page-breaking strategies and performance

2005-03-02 Thread Jeremias Maerki
Thanks. I think this has only to do with the rules to handle keeps and breaks and how to resolve conflicts. I don't think, however, that these parts create a restriction which tells us what page-breaking strategy to pursue. We could probably run with a first-fit strategy and still fulfill the

Re: page-breaking strategies and performance

2005-03-02 Thread Glen Mazza
Yes, I'm not in Simon's league here--I know very little about TeX--so I'll defer to you two on this issue. Just try to make sure that the final algorithm will help us support the keep-* properties. Thanks, Glen --- Jeremias Maerki [EMAIL PROTECTED] wrote: Thanks. I think this has only to do

Re: page-breaking strategies and performance

2005-03-02 Thread Jeremias Maerki
On 02.03.2005 17:05:55 Glen Mazza wrote: Yes, I'm not in Simon's league here--I know very little about TeX--so I'll defer to you two on this issue. I'm also still struggling. :-) Just try to make sure that the final algorithm will help us support the keep-* properties. Yes, the algorithm

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-03-02 Thread Simon Pepping
On Tue, Mar 01, 2005 at 09:15:37PM -0800, Glen Mazza wrote: OH!!! lightBulb state=on wattage=25/ Yes, you're right, Chris--now I see the issue. I implemented validation for about 80% of the FOs, but 80% is not 100%. fo:table-body never had any validation implemented, hence the NPE's

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java TableFooter.java

2005-03-02 Thread Glen Mazza
Thanks Simon. Glen --- [EMAIL PROTECTED] wrote: spepping2005/03/02 13:03:25 Modified:src/java/org/apache/fop/fo/flow TableBody.java TableFooter.java Log: Corrected a validation problem. Made TableFooter use TableBody's validation.

Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-03-02 Thread Chris Bowditch
Glen Mazza wrote: Hi Glen, OH!!! lightBulb state=on wattage=25/ Yes, you're right, Chris--now I see the issue. I implemented validation for about 80% of the FOs, but 80% is not 100%. fo:table-body never had any validation implemented, hence the NPE's that were occurring. I'm glad this issue