Manuel Mall wrote:
As far as I remember our last discussion was about who should generate the
Knuth element lists: The individual layout managers or the Line layout
manager. You argued in favour of retaining the current system and I tended
to favour the moving it up the hierarchy to the line LM.
I never spelled out why I am tending to favour the line LM. It all boils
down to in my mind: Do we need to create LM spanning Knuth elements? If
the answer is Yes then my gut feel is we are better off doing it at line
LM level instead of passing context around in argument lists. If the
answer is No then leaving it at lower level LMs is fine.
I see your point, and I agree with you that elements representing inline
spaces, borders and padding must take into account information coming from
multiple fo nodes.
Moving the generation to the LineLM level avoids the need to pass rich
(and large) context information to the children: but the downside is that
the children must give the LineLM their Positions, as the addAreas() phase
still counts on the Positions stored in the elements in order to know what
to place where (or we must rethink this phase too).
One reason to have LM spanning Knuth elements could be for consecutive
whitespace (BTW is it 'white space' or 'whitespace' - I don't have a
clue?)
The xsl recommendation 1.0 had "white space" (but "whitespace" in the
quotation from the css specs), 1.1 has both "white space" and "whitespace"
... they should really make up their mind! :-)
which we need to discard around formatter generated linebreaks. Or
which we may have to stretch/shrink for justification. What I am saying is
if whitespace-collapse="false" it may make things easier (and more
economic) if we model consecutive whitespace as a single glue element.
What is a more complicated case is having an fo:inline with border/padding
and whitespace before and after the border:
[example]
What about using the UnresolvedElements? Just as per the block-level space
resolution, each inlineLM could append at the beginning and at the end of
its element list an UnresolvedElement storing its border, padding and
spacing information.
Before performing the line breaking, when all UnresolvedElements are
known, their information can be combined to create the actual elements.
Another issue which came up since our last discussion but not really
related to the issue above is that because of markers we cannot do
whitespace handling at fo level in all cases but must rerun the fo level
type whitespace handling again at LM level when we have the actual
whitespace related property values which apply in the retrieve-marker
context as they can be different to the values of the same properties in
the marker context.
Maybe in this case we could use UnresolvedElements for the "inner" spaces
too (the spaces in the middle of a node text, whose handling in the
previous situation did not need other infrmation).
WDYT?
Regards
Luca
