Hi,

I haven't got any technical comments to the issues raised on the Wiki 
page. Is this 'too hard' or 'too boring' or 'too messy' or what? The 
problem is not going away. We currently don't do it right in some parts 
(that is established) but I don't know overall what is right or wrong. 
May be if I ask for comments on an issue by issue basis we get 
somewhere?

Quick background: In the default case (which seems to be the most 
complicated) white space handling consists of 3 things -

a) Replace any white space that is not as space char with a space char 
=> easy.

b) Collapse any sequence of spaces to a single space.

c) Remove any spaces at the beginning and end of lines.

First issue for b) and c) (and it may have different answers for b) and 
c)):

In other places the spec has a concept of a fence as a boundary across 
which certain operations do not apply, e.g. space resolution.

When FOP is collapsing (b) or removing (c) white space are there any 
fences we need to observe. For example a border/padding between two 
spaces, e.g. (spaces represented by a .):
<fo:block>...<fo:inline 
border="...">...Text ...</fo:inline>...</fo:block>
There are 4 sequences of 3 spaces each. What would we expect the final 
outcome to be (assuming it fits on one line):
a) all removed: [border]Text[border]
b) only first and last removed: [border].Text.[border]
c) first, 2nd and last removed: [border]Text.[border]
d) ???

To me b) makes sense. However, a) is the HTML way and c) seems what 
RenderX and AntennaHouse are doing. What do we want to do?

And what about this:
<fo:block>...A...<fo:inline 
border="...">...Text ...</fo:inline>...B...</fo:block>

a) all removed: A[border]Text[border]B
b) only first and last removed: A.[border].Text.[border].B
c) only first and last removed and others collapsed across the borders: 
A.[border]Text.[border]B
d) ???

a) is most likely wrong, b) looks OK, c) is the HTML way.

Manuel

Reply via email to