On Mar 7, 2007, at 09:07, Vincent Hennebert wrote:
Hi Vincent,
I have some questions regarding the handling of Position elements. I'm
not familiar with that part of the code yet, and as there is little or
no javadoc for those it's a bit difficult to guess their purposes just
by looking at the code.
I think you're not the only one with this problem... :/
Note that there is also an illustrious resetPosition() method, which
currently seems to be used nowhere. All references to it seem to be
circular. BlockLayoutManager.resetPosition() is only called by
AbstractLayoutManager.reset(), which in turn is only called by one of
the other LM's resetPosition(), etc.
The closest understanding that I have of those Positions is still a
bit limited, I'm afraid, so I'm hoping others chime in to correct my
mistakes or offer further clarification. (Just noticed that Luca
already did; will share my thoughts in any case, to see if I may have
misinterpreted something)
Anyway, AFAIU, a Position can be viewed as a kind of a pointer to a
position within the FObj.
The significance is roughly:
-> when the initial element list is constructed, each generated
ListElement receives a Position
-> after the breaking is done, and the areas get added, the Position
is used to get to the 'part' of the FO that corresponds to that
particular ListElement (and the right AreaInfos)
Auxiliary elements get null as a Position, since they generally do
not correspond to anything in the FO source. They are only added to
'steer' the breaking-algorithm in a certain direction.
Each break possibility can be said to correspond to such a Position.
In the addAreas() phase, IIC, the set of chosen break-points will be
presented as a List of Positions which are then iterated over (see:
PositionIterator, which is passed to addAreas())
Perhaps this is easiest to follow by means of an example:
When the TextLM creates the base element list, each Position it
generates and associates with one of its ListElements --a
LeafPosition in this case-- will correspond roughly to an index in
the character array... Actually, that's an index into the List of
AreaInfos, and those ultimately point to an index in the char array.
The AreaInfos correspond to words or fragments of hyphenated words.
The line-layout algorithm relies solely on the generated
ListElements, and does not deal with the Positions in the content
directly, nor with the AreaInfos.
Preserved linefeeds, for example, are 'translated' into separate
KnuthInlineSequences by the TextLM. All the LineLayoutManager gets to
see (collectInlineKnuthElements()) is a one-element sequence
containing nothing but a penalty (forced break), which it interprets
as a signal to end the current Paragraph, adding only an auxiliary
glue to generate an empty line if the Paragraph contains nothing but
the forced break.
Come to think of it, maybe this is a bad example, precisely because
no Position corresponds to the linefeed. :/
There is no AreaInfo, the index is simply skipped. (see:
TextLM.getNextKnuthElements() line 709)
Anyway, as far as I get the picture, the whole breaking-algorithm
operates entirely upon the ListElements, and ultimately translates
the set of chosen break-possibilities (= positions in the element
lists) into a List of Positions (associated to the ListElements), and
this latter list serves as base list for the PositionIterator that is
passed to addAreas().
What's the purpose of a LeafPosition? Of a NonLeafPosition?
IIC, then the key difference between them is that a LeafPosition will
have no sub-positions. They only have a position-index within a
NonLeafPosition. If that clarifies anything...?
What's the purpose of the wrapPositionElements method in
BlockStackingLayoutManager?
Subsidiary question: why would one sometimes
force the wrapping, sometimes not?
Judging from the code, in general this only has effects if the
calling LM is not the LM that is associated with a given ListElement.
The only exception seems to be ListItemLayoutManager, which forces
wrapping regardless of the base LM.
The purpose seems to be to create auxiliary Positions, such that an
element associated with a LeafPosition from one LM's point of view,
can be transformed into one that is associated with a NonLeafPosition
without losing the original Positions' info.
That is all: as far as I get it...
Cheers,
Andreas
