Jeremias Maerki wrote:
The computation, in itself, is easy, as the LineLM already has all the
necessary information: line width, unadjusted width, available stretch
and shrink.
It only easy if you have enough stretch and shrink available, right?
Well, we can always *pretend* it is enough! :-)
The question I'm asking myself is if the layout might be badly affected
by adjustments. If I get you right, the paragraph is not being rebroken
after the adjustment, since it stores the stuff in LineBreakPositions.
And even if it is rebroken, it can happen that you get one line break
more or less.
If the provisional ipd is over-estimated, the elastic objects in that line
will be stretched a bit more; this could not be optimal, but it would not
be terrible: the breaking algorithm, if needed, can already create line
breaks with an adjustment ratio > 1.
If the real ipd is bigger, however, the resulting line could be really too
narrowly spaced.
I like 2) better, too, but...
My only concern about 2) is that the re-computation logic would be put in
the LineArea class, while I always thought of the areas as objects
containg information but without any procedural behaviour.
Two/Multi-pass rendering comes to mind again. I think this is a question
of quality requirements. For most use cases it will be enough to simply
try to squeeze the effective content into the available space, but it
might not look optimal. For layout purists who don't mind about a
80-100% additional processing time a two-pass (or even multi-pass)
approach might be better and also easier to implement. It would need to
be configurable if we implement both variants.
Yes, undoubtedly a two-pass rendering would produce a better output: and
after all, even LaTex needs to be run twice if there are page number
citations.
Regards
Luca
