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


+ 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


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


Reply via email to