On Mon, 10 Oct 2005 09:38 pm, Luca Furini wrote: > Manuel Mall wrote: > > Is that actually conceptually the right thing to do, that is > > removing the trailing spaces before the end of a block as part of > > the Knuth handling? > > > > For leading spaces it is done somewhere completely different (and > > currently in the same piece of code it is done incorrectly for > > embedded spaces). > > I'm not sure it is the best place to do it, although I think that > before the breaks are computed trailing spaces should exist no more: > otherwise, the content width would take into account the width of > these spaces too, and right / center alignment could be incorrect. > > Moreover, a glue just before the elements appended by the LineLM > could be a feasible break, and this would create an empty page after > the last one with some content. > > In other words, that removal is there as it could not be performed > any later: but the sooner we get rid of the trailing spaces, the > better! :-) > > > I have a picture in mind with all white space handling done as part > > of the layout (area tree building) but before the actual Knuth > > sequences are constructed. But that's only a rough idea driven by > > the description of white space handling in the 1.1WD. > > Would you like to share it with us? I always find the specs quite > obscure as far as white space handling is concerned, so your > explanation could really be of great help! > This needs quite a bit more thought. Currently, and this is certainly shifting ground, I am considering the following approach. We need to pass whitespace handling information down the Inline LMs via the layout context. The layout context will have the basic information about the relevant values of the white space handling related properties and state information related to it as well. The state information may be just a counter for the number of consecutive eligible spaces encountered so far and some indication if anything has been generated so far. No Knuth elements for spaces are generated until a non space character is encountered. Then whitespace handling for the pending run of spaces is done. This may involve discarding the whole run if its the first in the block (and the white space properties allow it) or generating different Knuth sequences based on the setting of the white-space related properties. For example if we have suppress-before-linebreak we need a Knuth sequence that "throws the space away" if we break before it but "leaves the space" if we break after it. This gets even more interesting(?) if we have a run of spaces (non collapsing) but with suppress before/after/always around a linebreak. Again we would need to design the Knuth sequences to handle this correctly. Trailing spaces are handled by looking if any unhandled spaces are left when the getNextKnuthElements call returns to the top inline level (LineLayoutManager) and are then dealt with.
I feel a WIKI page upcoming similar to Jeremias space handling... > Regards > Luca Manuel
