xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 40230] - Invalid extra page break creates an undesired empty page
Date Fri, 11 Aug 2006 17:36:52 GMT
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 a_l.delmelle@pandora.be  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.

Mime
View raw message