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=40230>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=40230 ------- Additional Comments From [EMAIL PROTECTED] 2006-08-11 17:36 ------- (Here I go again :)) I think this could be handled before layout even kicks off... FOTreeBuilder could keep track of whether the currentFObj has area-generating content --shouldn't prove too hard to come up with a set of conditions that have to be satisfied. I'm thinking much in the same direction as the 'inMarker' instance member I recently added to FOEventHandler: a switch that is updated in the start- or endElement() event for each FObj. If it does not have any content, and the currentPropertyList contains a break-before/break-after property, instruct the current or the previous FO to discard that property (maybe log a warning, because it's not incorrect to specify it) Maybe we'd have to add a reference to the previousFObj/previousPropertyList to FOTreeBuilder as well, but that would be a small price to pay, and may open up perspectives in other areas. Sorry if I keep nagging about these 'normalizations' in the FOTree... :/ I guess my underlying goal is: whatever layoutengine/renderer combination processes our FOTree, we should try to offer it a representation of the tree that would be difficult to 'misrender'. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
