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 ...
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
?
Regards,
Luca
