Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by JeremiasMaerki: http://wiki.apache.org/xmlgraphics-fop/SpaceResolution The comment on the change is: Updates on the design and some additional details ------------------------------------------------------------------------------ http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200509.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200509.mbox/[EMAIL PROTECTED] - It appears that border and padding handling needs to taken into consideration, too, as they can both have conditionality elements. Following Simon's suggestion for creating space objects that are placed into the returned element list, we'd have to create objects for border and padding, too. + It appears that border and padding handling needs to taken into consideration, too, as they can both have conditionality elements. Following Simon's suggestion for creating space objects that are placed into the returned element list, objects for border and padding have been created, too. A new !ListElement class forms the new base class for !KnuthElement and for the new !UnresolvedListElement which is in turn the base class for a number of classes: - A special Position descendant will be needed to hold the resolved space-specifier so the LM that will be generating the space will have all the necessary information in addAreas(). After all, a single LM does not know with which other space from other LMs his space interacted. + * !BreakElement represents a break possibility and is very similar to !KnuthPenalty but holds additional unresolved list elements which need to be added in the break condition. The !SpaceResolver later transforms the !BreakElement into a !KnuthPenalty. + * !BorderElement represents a (possibly conditional) border. + * !PaddingElement represents (possibly conditional) padding. + * !SpaceElement represents an unresolved space specifier + + All these elements will be inspected by the !SpaceResolver class where the space resolution and the handling of the conditional lengths is handled. The output is a modified element list with no unresolved elements. !SpaceResolver.resolveElementList() is called to resolve all unresolved elements prior to the breaking process. + + Two special Position descendants are used to hold the resolved space-specifier so the LM that will be generating the space will have all the necessary information in addAreas(). After all, a single LM does not know with which other space from other LMs his space interacted. !SpaceHandlingBreakPosition is used to notify the involved layout managers about the resolved space specifiers and conditional lengths in a break situation. !SpaceHandlingPosition does the same for the no-break situation. The layout managers are always informed through the !ConditionalElementListener interface just before a part (page/flow/line) is painted (addAreas stage) by calling the !SpaceResolver.performConditionalsNotification(). + + In the case where a penalty holds a special Position instance (like for tables) this Position has to be exchanged for the !SpaceHandlingBreakPosition, but this class will hold the original Position object which will be restored by the parent LM's addAreas() method after all layout managers have been notified. '''Reminder''': an empty block (<fo:block/>) will not split a space-sequence, but !BlockStackingLayoutManager currently adds a box (w=0) to the element list so an "id" present on the empty block will still be registered by a later addAreas(). This will interfere with the correct detection of space-sequences. This will need to be looked at, eventually. (Case 3d under 4.2.5 Stacking constraints!) Someone seems to have started space-start|-end support (see !SpaceSpecifier and stuff in !LayoutContext) long ago, before we introduced Knuth approach. We'll have to revisit that since this has currently no effect on the inline element list but only on the areas produced. That means that if you specify a space-start on an fo:inline you will get a space but line breaking will be off. I hope we'll be able to use the stuff I'm building for inline-level spaces, too. - == Design == - - This describes the design I'm currently trying to implement. Instead of creating boxes, penalties and glues directly, the LMs create so-called unresolved elements for aspects like border, padding, spaces and break possibilities. In order to do this a new class !ListElement is introduced which serves as base class for both !KnuthElement and the new !UnresolvedListElement. !UnresolvedListElement is subclassed by !BorderOrPaddingElement, !SpaceElement and !BreakElement. The !SpaceResolver is tasked with resolving all the unresolved elements by handling element list generation for conditional lengths (border and padding) and spaces. The space resolver searches for sequences of unresolved elements and handles each sequence separately. It also looks for break possibilities which it handles accordingly. - - This approach makes it relatively simple to handle the space resolution rules. A little uncertainty remains for the table LM which creates element list a little differently but since it's generated element list is not much more complicated than that of the other LMs this shouldn't be a big problem. - - The big problem right now is to determine the right strategy to react on break decisions made by the breaker. Currently, the resolution code creates a relatively simple element list which collapses all elements into the basic pattern described on top of this page. That means that currently all the Position instances held by the individual unresolved elements get lost. There's also the added complexity that the break case's resolved result (spaces, paddings etc.) can be quite different from the non-break case. It's not a simple 1:1 relationship between Knuth elements and Position instances and each LM expects its own Position elements in order to properly react to them. - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
