1) What is the purpose of 2 glues for a normal space in END and START alignment:
new KnuthGlue(0, 3 * wordSpaceIPD.opt, 0, , false)); new KnuthPenalty(0, 0, false, , true)); new KnuthGlue(wordSpaceIPD.opt, - 3 * wordSpaceIPD.opt, 0, , true));
[Luca Furini]
The purpose is to give each line (but the last one) the same stretchability, regardless of the number of spaces in it.
If the penalty is not used (there is no line ending there) the overall effect of the 2 glues is a 0 stretchability and does not modify the line total; if the penalty is used (a line ends there) then the stretchability of the previous glue is added to the line total, which becomes 3 * wordSpaceIPD.opt because the previous space, as said before, added 0 (the following glue is suppressed).
In justified text, a line with many spaces can be adjusted in order to be much shorter, or much longer. If left-aligned text used the same elements, the algorithm would find the same breaking points; but this time adjustment ratios are not used, so a line with many spaces would be too much longer, or too much shorter, than the other lines. Using these elements, the algorithm creates lines whose unadjusted width is quite the same.
Ok, thank you for the explanation.
I'm still not sure why it would be ok to ignore any user specified min and max values of 'word-spacing' during START and END alignment. If a user specifies a length range, what would the reason be for not using it? Perhaps with additional DEFAULT_SPACE_WIDTH.
And why not adjust the spacing within the user specified min/max for START and END alignment?
3) What is the reasoning for doing hyphenation only after threshold=1 fails. Naive common sense tells me that if the user specify hyphenation we should do hyphenation before finding line breaks.
Finding hyphenation points is time-expansive (all words must be hyphenated, not only the ones "near a line's end"), the sequence of elements becomes longer, there are more feasible breaking points, and a line ending with a "-" is less beautiful; so I thought that if a set of breaking points could be find without hyphenation.
I just took the "hyphenate" property as a suggestion instead of an order! :-)
Note that the same algorithm with the same threshold could find a different set of breaking points with and without hyphenation, because the elements are different. Without hyphenation, spaces could need a little higher adjustment, for example.
Ok, performance is indeed a fine reason, but IMHO such quality vs. speed tradeoffs should eventually be made by the user rather than us.
Thank you for taking the time to explain it all in such great detail.
regards, finn
