> 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 handling:
>   * white-space-treatment="ignore-if-*"
>   * the CR does not follow/precede a linefeed
>   * it is the first character in a sequence of whitespace, so
>     it survives white-space-collapse

Shouldn't a CR always survive whitespace handling? For a starters it is
fairly difficult to get a CR out of a XML parser. Only if the CR is hidden
in an entity reference can it survive. Also, as Simon pointed out in some
other contribution, whitespace handling is designed to deal with pretty
printing and readable XML layout introduced whitespace. A CR preserved by
the XML parser certainly does not fall into that category. I am also not
aware that the XSL-FO spec mentions CR as falling under whitespace. IMO
for whitespace handling CR is just a non whitespace character.

So, we only need to consider what fop layout should do if it encounters a
CR. I would say, keep it simple, throw it away and log a warning.

> Now, what about a tab character under the same circumstances? Do we
> use an elastic width of X spaces optimum, where X is purely
> conventional?

Similar considerations as for CR apply to TAB.

Any way both CR and TAB have not much to do with the problem at hand: NBSP
not handled correctly.

>> The non breaking sequences are probably very simple:
>> 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.
>> Curious what Luca and others think. Are the above two cases OK for
>> NBSP or have I oversimplified and missed something, that is for the
>> text-align values other then "justify", that
>> is "start", "center", "end", is it enough to just reserve
>> a fixed width for the NBSP?
> Still depends on text-align-last, no?

Yes correct but even then do the two rules above suffice, i.e. possible
justification required: Rule 1; no justification required: Rule 2?

> BTW, is this not one of those situations where it's possible that the
> used font contains a glyph for the NBSP character, so we should check
> that as well?

Yes but again it has very little to do with the problem. If the font has a
glyph for NBSP we should use that glyphs width and not the SP width in the
glue elements generated. That's all.

> Cheers,
> Andreas


Reply via email to