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: Notes about the design I'm currently implementing ------------------------------------------------------------------------------ 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. - 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. + '''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. 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]
