On Thu, 3 Nov 2005 06:03 am, J.Pietschmann wrote:
> Manuel Mall wrote:
> > a) Yes UAX#14 always breaks at the of a sequence of spaces
> > b) But is also says that it assumes any trailing spaces in a line
> > are being removed
> > This "conflicts" with XSL-FO which can force spaces being retained
> > therefore adjustments to the algorithm are necessary to cater for
> > that.
> Computing line breaking opportunities and discarding whitespace at
> the end (or beginning) of a line are different matters. If whitespace
> has to be retained, trailing spaces after a non-space string may
> simply mean the previous line breaking opportunity has to be used,
> because otherwise the string including the trailing spaces will
> overflow the line area. The trailing whitespace may also influence
> text justification.
Hmm, to me it appears that UNICODE and XSL-FO have slightly different 
models when it comes to white space in the context of line breaking 
which is causing the discussion here. In UNICODE everything is based 
simply on the properties of the codepoint in question and its 
neighbour. In XSL-FO one can change the behaviour of a codepoint by 
setting those white space related XSL-FO properties. That is not a 
concept within UNICODE. If you want to retain white space in UNICODE 
you use a different codepoint. If you want to retain a space in XSL-FO 
you could use a different codepoint but more likely you set a XSL-FO 
property if you want this applied widely in your document.

If we want to 'marry' UNICODE linebreaking with XSL-FO white space 
handling we have this interaction to consider. One possible solution 
would be to replace spaces (U+0020) by different codepoints which 
resemble the behaviour modification imposed by any XSL-FO white space 
handling properties in effect. But I am not sure if this can be done in 
all cases. Otherwise we may have to modify the UNICODE line breaking 
algorithm to cater for the XSL-FO white space specialities.

> J.Pietschmann


Reply via email to