Re: [Bug 29124] - New line breaking algorithm

[Luca Furini <lf...@cs.unibo.it>]

Simon Pepping wrote:

> > - word spacing and letter spacing are now fully implemented, they can
> > both have MinOptMax values; but I am still thinking about how to
> > differentiate a user-defined zero value from a default zero value ...
>
> You cannot. A default value is a user-defined value supplied by the
> system to save the user the trouble of always having to enter a
> value. It is just a convenience, and you cannot attach a different
> meaning to it.

You are right: default values must be respected no less than expressed
values, I asked the wrong question.

The point is that the XSL recommendation states that the default
word-spacing value is "normal", meaning "The normal inter-word space, as
defined by the current font and/or the UserAgent", not zero.
At the moment, the SpaceVal variable in the TextInfo object used by the TLM
has
     .getSpace().min == .getSpace().max == 0
even if the word-spacing property was not set in the fo document.

So, the right question is: how can the TLM see if the word-spacing property
value is "normal"?

> > - text-align-last is partially implemented; text-align-last = "justify"
> > works only if text-align = "justify" too; this is because Knuth's
> > algorithm doesn't  provide for a different alignment for the last line.
>
> TeX uses glue to achieve this, \parfillskip. It is the special amount
> of glue appended to the last line. In the TeXbook, p. 99, Knuth
> describes it as 'the special trick that allows the final line of a
> paragraph to be shorter than the others'. Setting \parfillskip to 0
> removes this ability. Usually \parfillskip has infinite
> stretchability.

I fear this trick works only with justified text.
Knuth's book suggests a way to implement right/left and center alignment
which is not just "justify text and then ignore the computed adjustment":
this different strategy involves using special sequences of elements
representing spaces.
For example, with left (or right) aligned text each space generates the
sequence:
    glue(width 0, stretch X, shrink 0)
    penalty(value 0)
    glue(width word-space-width, stretch -X, shrink 0)
If the line is not broken after the first glue element, the overall sretch
of these elements is 0: so, the total available stretch of each line is
always X, regardless of the number of spaces, while with the justified-text
strategy the more spaces are in a line, the more stretch that line will
have.
The computed adjustment ratio refers to this constant value, and it is
completely useless if we want to justify the last line. We could use the
computed difference to calculate the space adjustment, but we don't know how
many spaces there are in the line.
Setting \parfillskip to 0 does not avail, as it just forces the algorithm to
find lines all with the same width.

Maybe, with text-align = "left", "right" or "center" and text-align-last =
"justify" we should use the justified-text strategy with stretchable and
unshrinkable spaces.

Regards,
    Luca

Re: [Bug 29124] - New line breaking algorithm

[Finn Bock <bc...@worldonline.dk>]

Simon Pepping wrote:

> TextInfo derives that value from the value of the word-spacing
> property.
> 
> That must be an error in the property handling by FOP. 

Yes. I'll commit a fix for it tomorrow.

> In
> FOPropertyMapping 0pt is used as the default value. Apparently
> "normal" should be the default value. I am not sure how this can be
> done for a space property. Something similar happens for length
> properties, which can have the default value "auto". I think "normal"
> should be a keyword. 

Keywords are for mapping one value into another value before the values 
are parsed. In this case 'normal' should be implemented as an enum.

> Apparently, the actual value can only be
> calculated at layout time, when the font is known.

Yes, so the consumers of the 'word-spacing' value must must check if the 
value as an enum == NORMAL before using the value as a Space:

     Property wordSpacing = propertyList.get(PR_WORD_SPACING);
     if (wordSpacing.getEnum() == NORMAL) {
         textInfo.wordSpacing = new SpaceVal(
                new MinOptMax(min, opt, max), true, true, 0);
     } else {
         textInfo.wordSpacing = new SpaceVal(wordSpacing.getSpace());
     }

regards,
finn

Re: [Bug 29124] - New line breaking algorithm

[Simon Pepping <sp...@leverkruid.nl>]

On Thu, Aug 12, 2004 at 12:27:38PM +0200, Luca Furini wrote:
> 
> The point is that the XSL recommendation states that the default
> word-spacing value is "normal", meaning "The normal inter-word space, as
> defined by the current font and/or the UserAgent", not zero.
> At the moment, the SpaceVal variable in the TextInfo object used by the TLM
> has
>      .getSpace().min == .getSpace().max == 0
> even if the word-spacing property was not set in the fo document.
> 
> So, the right question is: how can the TLM see if the word-spacing property
> value is "normal"?

TextInfo derives that value from the value of the word-spacing
property.

That must be an error in the property handling by FOP. In
FOPropertyMapping 0pt is used as the default value. Apparently
"normal" should be the default value. I am not sure how this can be
done for a space property. Something similar happens for length
properties, which can have the default value "auto". I think "normal"
should be a keyword. Apparently, the actual value can only be
calculated at layout time, when the font is known.

Simon

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: [Bug 29124] - New line breaking algorithm

[Finn Bock <bc...@worldonline.dk>]

[Luca Furini]

> The point is that the XSL recommendation states that the default
> word-spacing value is "normal", meaning "The normal inter-word space, as
> defined by the current font and/or the UserAgent", not zero.
> At the moment, the SpaceVal variable in the TextInfo object used by the TLM
> has
>      .getSpace().min == .getSpace().max == 0
> even if the word-spacing property was not set in the fo document.
> 
> So, the right question is: how can the TLM see if the word-spacing property
> value is "normal"?

Take a look at the way WORD_SPACING is assigned now in PropertyManager. 
I assume some other MinOptMax value should be used when the enum value 
is NORMAL but I don't know exactly where the value should come from.

Anyway, I hope this is a step in the right direction.

regards,
finn