Manuel Mall wrote:
c) Your initial thought is that the Line LM should then provide enough
information to the LMs to generate their Knuth sequences while my
initial thought is that the Line LM generates the Knuth sequences and
provides enough information for the LMs to generate their areas.
If you agree with this summary may be we can concentrate on discussing
the pros and cons of the two approaches mentioned in item c) above?
Who should generate the elements?
1) the inline LMs
pros:
+ the LineLM needs to know only the text from its inline children
+ the LineLM would work only on the collected text; the output that must
be sent to the inline LMs (the set of breaking points, hyphenation points,
collapsed spaces) would be quite simple
+ each inline LM already knows the relevant properties affecting the size
of the elements (font-size, word-spacing, letter-spacing, borders and
paddings) so the generation would be easily done
+ while creating the elements, the inline LMs uses the same information to
create area properties
cons:
- many function calls to get the elements (another tree walk of the LM tree)
- [add your cons here!]
2) the LineLM
Well, the inverted pros and cons!
My main concern about this approach is complexity: while the text is a
"flattened representation" of the fo tree, so that the LineLM can easily
find all kind of breaking / hyphenation points regardless of fo
boundaries, the properties cannot be so easily flattened; in order to know
the font-size of a character the LineLM would need either a lot of
information (where each fragment starts and ends, and two nested inlines
can define up to 5 "fragments") or a tree (but in this case whouldn't it
be quite similar to the LM tree?).
But maybe I just have not yet understood your idea ...
Regards
Luca
