Manuel Mall wrote:
IMO nbsp (and any other Unicode special spaces) are outside the scope of
XSL-FO whitespace handling. XSL-FO refers to whitespace as defined in
XML. In XML only x#20, x#9, x#a, and x#d are considered whitespace.
Therefore nbsp does not need to be considered when looking at
white-space-treatment and white-space-collapse. Would that approach
remove the complications you mentioned?
Thanks for the clarification, Manuel!
This solves the first supposed problem (interaction between nbsp and
pretty-printing spaces), but the second one is still open: what happens if
we have
someContent<nbsp><space>otherContent ?
*IF* (and I'm not at all sure about this) there can be a break , then both
spaces should be discarded: in order to implement the correct behaviour
for this almost hypothetical situation, we would need to create elements
for both spaces as a whole (and thay could belong to different LMs)
otherwise the algorithm would not be able to ignore the nbsp during the
line breaking.
Anyway I think this is quite an unlikely combination of entities and
properties :-) ; as I see you are already working on something else, for
the moment I will prepare a patch for the most common situations.
Regards
Luca
