On Fri, 30 Dec 2005 11:25 pm, Andreas L Delmelle wrote:
> On Dec 30, 2005, at 14:54, Manuel Mall wrote:
> > On Fri, 30 Dec 2005 09:38 pm, Andreas L Delmelle wrote:
> > <snip/>
> >
> >> Case not covered by the altered code (but I didn't think it to be
> >> a showstopper):
> >> <snip />
> >
> > Hmm, isn't that a step backwards from the status before you applied
> > the
> > patch?
>
> Not really. Just had to draw a line somewhere... If you do it for the
> last inline in a block, then you would also have to do it for the
> last inline of the last inline of a block etc. Besides, you get a
> second pass anyway, when the line is built. All the trailing space-
> glyph-areas could be removed there (but they currently aren't anyway,
> depending on text-alignment).
>

I am still not sure if this is not a step backwards.  Before the model 
was: All whitespace handling apart from dealing with whitespace around 
FOP generated linebreaks is done during the initial refinement.

Now this is not really the case any more and the line breaking stuff 
would have to deal with treating whitespace in other places than around 
its own generated linebreaks as well. I was hoping we could get rid of 
the trailing paragraph space removal code in the line breaking 
algorithm as it is one of those areas causing trouble again and again.

> >> I explicitly excluded fo:leaders from white-space handling,
> >> because for example:
> >>
> >> <fo:leader leader-pattern="use-content">   xxx   </fo:leader>
> >>
> >> Collapsing the three spaces to one may produce unintended results.
> >>
> >> OTOH, if you have a nested inline in a leader, then the
> >> white-space for the inline will be treated...
> >
> > Is there an indication in the spec that whitespace around
> > use-content leader patterns should be treated any different? If
> > not, I would include it into the normal white space handling.
>
> This was more based on expectation than on anything I encountered in
> the specs, I guess. The white-space around the leader --physically
> outside of the fo:leader element-- is treated according to the type
> of parent it belongs to. The spaces inside the content of the
> fo:leader are left alone. Somehow, even with white-space-
> collapse="true", I'd much more expect the end result to mimic:
>
> <fo:leader leader-pattern="use-content">...xxx...</fo:leader>
>
> than
>
> <fo:leader leader-pattern="use-content"> xxx </fo:leader>
>

Actually I wouldn't (assuming default white space handling property 
values). What do others think?

> <snip />
>
> Cheers and Best Wishes for 2006.
>
> Andreas

Same to you

Manuel

Reply via email to