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


"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]

Reply via email to