Finn Bock wrote:

> 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));

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.

> and why isn't the min and max of wordspaceIPD used.

Well, you just made me notice there is a little bug,
LineLayoutManager.DEFAULT_SPACE_WIDTH should be used insted! :-)

It's just a "magic number": the point is that every TextLM should use the
same value.

> 2) What does the threshold parameter to findBreakingPoints controll?
> It seems to be a performance parameter which control the number of
> active nodes, rather than a quality parameter.
> Or to frame my question
> differently, if threshold=1 finds a set of breaks, will threshold=5
> always pick the same set of breaks? Or can threshold=5 find a better set
> of breaks?

It controls both performance and quality: minimum quality.

If threshold = 1 finds a set of breaks, it is the best possible set of
breaks, because the adjustment ratio of each break is <= 1 which means
that spaces and other adjustable objects will not need to be longer than
their .max width.

But with this optimal threshold the algorithm could fail, and find no set
of breaking points; so, a try with a higher threshold must be done.

If with threshold = 1 a set is found, with threshold = 5 the same set
would be found, but it would take more time, because a greater number of
active nodes are used.

> 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.

> 4) I've compared your code to tex_wrap
> and the main difference is in the way new KnuthNodes are added to the
> active list. Is the BestRecords part of Knuth or is it your own
> invention? Why is it only fitness_class'es in BestRecord that is higher
> then minDemerits + incompatibleFitnessDemerit that is added to
> activeList? Why not all fitness_class'es in BestRecords?

At the moment I don't have the book at hand, but I am quite sure it's
*not* an invention of mine! :-)

As far as I can remember, the Knuth book uses 4 different variables, named
C1, ... C4 :-( (or maybe D or A, anyway not a very self-documenting name!)
and I just created this structure to store them.

I'll try and find some time to look at this ...

Thanks for your interest and your comments, they are most welcome!


Reply via email to