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

Reply via email to