Peter, Here's my point of view on where line-breaking (perhaps including hyphenation) happens.
The end result of layout is a sequence of nested areas. However while layout is happening, line-breaking logic has to "pretend" that it's only working on a flat row of characters and other inline leaf nodes like external graphics. Keiron and I took different approaches to this, but the idea is about the same: lower level layout managers return information to the Line Layout Manager which allows it to make a decision about where to break the line. Once that decision is made, the appropriate areas can be created, depending on where the break occurs. Although it's possible to send information about IPDim down to lower level inline layout managers, I think it's simpler and clearer to concentrate knowlege (and strategy) about line-breaking in a single layout manager: the one actually creating Line Areas. There's a strong analogy with block-direction layout, where the Flow level (or perhaps the Page level?) LM is responsible for determining column/page breaks based on information provided by the lower level layout managers. The Flow and Line level LM are also responsible for "justifying" in either the inline or block progression dimensions and deciding how much stretch or shrink should be done. They either pass this information down to lower level layout managers (that was my plan) or do it directly on the flattened areas (Keiron's approach, at least at the line level). -Karen "Peter B. West" wrote: > ....... > This leaves a question about where hyphenation is decided. In 4.7.2 > point 5, there is a discussion about glyph substitution, insertion and > deletion which seems to assume that the sequences of inline-areas being > built into line-areas are in fact fo:characters. The corresponding > sequences bubbling up from fo:inline and fo:basic-link are already > wrapped as integral inline-areas and presented as a fait accompli to the > parent line-builder. > > The fo:inline/fo:basic-link fo must obviously receive IPDim and BPDim > information in order to present sane integral inline-areas to its > parent, and to allow for the layout of nested fo:blocks. (This is pure > hierarchical galley stuff.) In any case, there should be a correspondent > in 4.7.3 to the discussion of substitution, insertion and deletion in > 4.7.2, just to make it clear what the responsibilities of the > inline-builder are. That's if I have this right, this time. What do you > think? > Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
