On Fri, 6 Jan 2006 04:56 am, Andreas L Delmelle wrote: > On Jan 5, 2006, at 18:48, Andreas L Delmelle wrote: > > <snip /> > > To summarize this thread (it has taken long enough :-)) > > I thought it over a bit more, and what I'm currently working on (and > will most likely finish during the weekend) is the following: > > 1) Basically keep the algorithm the way I recently altered it, but > containing some additional processing for trailing inline FOs that > end with a sequence of white-space. Determining this last bit is easy > enough, since it just means that XMLWhiteSpaceHandler.inWhiteSpace > will be false after handleWhiteSpace(). At the end of the block, we > will do one more pass over all those trailing inlines, if any. > IMO, in the vast majority of use-cases there will be either zero, one > or at most two of those, but theoretically this could be any > number... If there are any, then if white-space-collapse has the > default value of "true" there will be only one trailing white-space > character left at that point, so this additional bit of processing > will cost virtually nothing. > > 2) Simplify the CharIterator structure, in the sense that we'll still > only need an iterator over FOText and Characters. Unless layout needs > access to the iterators, I think charIterator() can be pushed down to > be specific to FObjMixed, and then the overrides of this method can > be removed from all other FOs apart from FOText and Character. For > 1), it could turn out handy if I add the possibility to iterate > backwards until the last non-white-space is encountered... > > 3) Exclude markers (and their descendants) from white-space handling > during refinement, for the mentioned reasons: > * retrieve-marker's ancestor's white-space properties govern the > treatment in this case > * possibly page-break context is needed when dealing with > alternating static-contents > * retrieve-markers with retrieve-boundary="document" > > 3) of course means the recently enabled marker_bug.xml testcase will > have to be disabled again until we find a way to tackle this in > layout. I had thought of using XMLWhiteSpaceHandler itself for this, > but the tricky part is that, once a Marker (and its descendants) have > been white-space-treated, the stripped white-space is permanently > gone, and since that same Marker can again be retrieved in a > different context etc. > > [end-of-thread, I hope ;-)] >
Thanks for the summary and yes I think we are at the end of this one. Personally I would not do 3) at this point in time, that is I would not exclude markers from the whitespace refinement. IMO the whitespace handling properties will have their default values (or matching values in the marker and retrieve-marker contexts) most of the time and therefore the current handling produces better results more often than by reverting that part of the patch. But this is a judgement call and I am not really fussed. There is a testcase which shows how it fails when the properties are not matching and this should suffice to document the problem. > Cheers, > > Andreas Manuel
