On Thursday 02 February 2006 17:46, Luca Furini wrote: > 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). >
Yes, I am aware of this. One of the reasons I used the term 'tending to favour'. I am still not clear in my mind on all the implications and trade-offs. It certainly would be less disruptive to the overall code structure to leave the element generation within each LM. > > 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. > I don't know anything about the UnresolvedElements as I so far have not studied the block level LMs. But this reminds about another requirement we may need to consider: Proper conditional start/end space resolution. This is currently not done. I don't think we even have testcases for it. When Jeremias did the block level before/after stuff the idea was that may be we can port this to the inline LMs for the start/end space resolution. > > 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? > Not sure here - I am more inclined to reuse the fo logic, that is iterate over all characters in a paragraph and tell the LMs which one to delete probably combined with the Unicode UAX#14 linebreaking. > Regards > Luca Manuel
