Manuel Mall wrote:
1. The suppress-at-line-break property can be applied to all characters.
I would take the position at the moment that explicit specification of
the suppress-at-line-break property is not supported and we worry about
it at a later stage. I would certainly argue against just
On Monday 06 February 2006 18:44, Luca Furini wrote:
Manuel Mall wrote:
snip/
1. Justified text: pen INF + elastic glue
2. All other justification modes: either just a box of the width of
the space or pen INF + fixed width glue.
I think in both cases (justified / unjustified text) we
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
On Monday 06 February 2006 22:35, Luca Furini wrote:
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.
Manuel Mall wrote:
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
someContentnbspspaceotherContent ?
*IF* (and I'm not at all sure about this) there can be a break , then
both spaces
On Feb 6, 2006, at 08:17, Manuel Mall wrote:
[ME:]
snip/
A preserved carriage return can be treated the same way as a
linefeed, under the very exceptional condition that it survives
white-
space handling:
* white-space-treatment=ignore-if-*
* the CR does not follow/precede a linefeed
On Feb 6, 2006, at 17:04, Luca Furini wrote:
Hi Manuel / Luca,
Manuel Mall wrote:
IMO yes there can be a break and no only the space needs to be
removed. Again the argument is that nbsp is not whitespace as per
XSL-FO definition and need not to be removed.
What makes you think that
On Feb 6, 2006, at 19:40, Andreas L Delmelle wrote:
Currently, the fact that it is a fo:character is not known when
running this through the algorithm. The CharIterators deal with the
characters.
Say... I was just wondering: why does the TextLayoutManager create
its own copy of the
On Feb 5, 2006, at 14:13, [EMAIL PROTECTED] wrote:
Hi Manuel,
--- Additional Comments From [EMAIL PROTECTED] 2006-02-05
14:13 ---
Jeremias, no that is not it IMO. Knuth doesn't break between
elements as such.
The glue or penalty element itself is the break opportunity and is
On Feb 5, 2006, at 14:13, [EMAIL PROTECTED] wrote:
Hi Manuel,
--- Additional Comments From [EMAIL PROTECTED] 2006-02-05
14:13 ---
snip/
A preserved carriage return can be treated the same way as a
linefeed, under the very exceptional condition that it survives white-
space
10 matches
Mail list logo