On Wed, Nov 17, 2004 at 02:25:02PM +0100, Luca Furini wrote: > Simon Pepping wrote: > > > Marker extends FObjMixed, which adds InlineStackingLM. This is a > > problem. In the new model there should be a strict separation between > > LMs implementing InlineLevelLM and those that do not. InlineStackingLM > > does not, and probably should not do. > > I still have to really understand InlineStackingLM, I find it very > enigmatic! It generates inline areas, but it has LineLM as a subclass ...
I think it is only there as a common superclass of InlineLM and LineLM. No FO object should add this LM in its addLM method. Perhaps it should get a private constructor. Currently FObjMixed and BiDiOverride use it. > Maybe it should implement both getNextBreakPoss and getNextKnuthElements: > looking at the retrieve-marker's parent and / or at the marker's children > should be enough to decide whether to call the one or the other. > > Anyway, I was wondering whether it is really necessary to add a new LM. > > If the fo tree is > > fo:page-sequence > -----------+----------- > | | > fo:static-content fo:flow > | | > ... ... > | | > ret. marker's parent marker's parent > | | > fo:retrieve-marker fo:marker > ---+--- > | | > chld1 chld2 > > at the moment, RetrieveMarkerLM tries to achieve this (in the LM tree): > > ... > | > parentLM > | > RetrieveMarkerLM > | > InlineStackingLM > ---+--- > | | > chldLM1 chldLM2 > > but, as a marker can only have children which could replace its > retrieve-marker, wouldn't it be better to have just: > > ... > | > parentLM > ---+--- > | | > chldLM1 chldLM2 I have been thinking along the same lines. fo:wrapper does a similar thing. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
