Detach PSLM from LayoutManager?

[Glen Mazza <gm...@apache.org>]

Team,

I would like to tighten up the PSLM a little bit
more--namely, I'm inclined to have PSLM stop extending
AbstractLayoutManager or even implementing the
LayoutManager interface.  With this change, PSLM will
no longer need to have unused empty methods within it,
and will be as robust, independent, and precisely
coded for its task as our other standalone LM
RootLayoutManager (aka AreaTreeHandler) is.

Currently I see 4-6 methods that will no longer need
to be implemented by PSLM under such a scenario:

    void setFObj(FObj obj);
    void setParent(LayoutManager lm);
    LayoutManager getParent();
    void initialize();
    boolean isBogus(); (possibly)
    boolean generatesInlineAreas(); (possibly)

And as things become better clarified, it is possible
even more methods will become obsolete for it.

Once done, I would like to add a getPSLM() method to
the LayoutManager interface and remove the following
PSLM-only implemented methods from it:

void addIDToPage();
PageViewport getCurrentPageViewport();
PageViewport resolveRefID();
Marker retrieveMarker();
LayoutManagerMaker getLayoutManagerMaker();
void addUnresolvedArea();
void addMarkerMap();

(I can't add a getPSLM() without the change at the top
because of the circular reference between PSLM and LM
that would result.)  

Henceforth, all calls from the various LM's to these
methods will consist of getPSLM().addUnresolvedArea(),
getPSLM().retrieveMarker(), etc., instead.  
This change will much better anchor and make more
readable these function calls within the various LM's,
because it will show that these methods are
implemented in only one place (PSLM), and not the
child LM itself. It will also reduce the demands on
those wishing to extend LM by removing the need for
them to trivially implement these methods (i.e., no
more recursive getParentLM().retrieveMarker(),
getParentLM().addUnresolvedArea() methods in these
child LM's.  This will be needed for only one method,
the new getPSLM().)

There is no rush on this--and this can easily wait
until the Knuth work is better solidified.  But I
would like to know your thoughts and comments
here--there may be other issues I had not thought of
in proposing this change.

Thanks,
Glen