>
> Manuel Mall wrote:
>
>
> This also solves another bug concerning a nbsp being removed when starting
> a line.
>
> I'll make the commit in a few minutes
>
Thanks Luca, good stuff and what a nice side effect that something else is
fixed as well.
As you done the fix I think I leave the honour t
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 Feb 7, 2006, at 01:07, Manuel Mall wrote:
On Tuesday 07 February 2006 01:11, Andreas L Delmelle wrote:
On Feb 6, 2006, at 08:17, Manuel Mall wrote:
For a starters it is fairly difficult to get a CR out of a XML
parser.
Difficult? It's simply a characters event, just like any other...
On Tuesday 07 February 2006 01:11, Andreas L Delmelle wrote:
> On Feb 6, 2006, at 08:17, Manuel Mall wrote:
> >> [ME:]
> >
> >
> >
> >> A preserved carriage return can be treated the same way as a
> >> linefeed, under the very exceptional condition that it survives
> >> white-
> >> space handling:
On Tuesday 07 February 2006 00:04, Luca Furini wrote:
> 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
> >>someContentotherContent ?
> >> *IF* (and I'm not
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 FOText
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 both
On Feb 6, 2006, at 18:11, Andreas L Delmelle wrote:
A carriage-return can survive white-space-handling, for instance,
in the following case (suppose Mac-encoding):
First line, then a CR
some spaces, and more text
Cool! I just realized that this would be one way to preserve
'linef
On Feb 6, 2006, at 08:17, Manuel Mall wrote:
[ME:]
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
* i
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
someContentotherContent ?
*IF* (and I'm not at all sure about this) there can be a break , then
both spaces should be disc
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:
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
w
On Monday 06 February 2006 18:44, Luca Furini wrote:
> Manuel Mall wrote:
> >
> > 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)
Manuel Mall wrote:
The problem is the coding model used for Knuth element element generation for
spaces is flawed. What is done is that the only difference between normal space
and NBSP is an infinite penalty at the beginning of the sequence. However, some
sequences are pretty long and involve
> On Feb 5, 2006, at 14:13, [EMAIL PROTECTED] wrote:
>
> Hi Manuel,
>
>> --- Additional Comments From [EMAIL PROTECTED] 2006-02-05
>> 14:13 ---
> A preserved carriage return can be treated the same way as a
> linefeed, under the very exceptional condition that it survives white-
> space h
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
disca
16 matches
Mail list logo
