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 . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

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 . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

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 "bes

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.

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 . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

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 . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

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 --- Jere

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 condit

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 rules

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 algor

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!!! > > 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. Yo

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!!! 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 has finally been resolved, tha