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 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>
<snip />
Didn't your patch fix the marker_bug.xml testcase? If so it can
come out
of the disabled-testcases.
Yep, it did. Completely forgot about that. Thanks for pointing out.
Cheers and Best Wishes for 2006.
Andreas
