From: Martin Sevior (email@example.com)
Date: Mon Apr 22 2002 - 11:21:18 EDT
To make the Tables/footnotes/positioned objects work we need
additional fl_Layout classes as well as the fp_Container classes. The idea
of course is to rewrite as little as possible of our current code.
The fl_Layout classes contain the logical assembly of text and images
in the document.
Currently our fl_Layout classes consist of:
fl_Layout - generic Base class.
fl_DocLayout - overall class for the entire document - contains all
the sectionlayouts and pages.
fl_SectionLayout - generic SectionLayout for collecting groups of
fl_DocSectionLayout - Collection of fl_BlockLayout's within a given
section of the document. It positions lines in
fl_HdrFtrSectionLayout - Collection of fl_BlockLayout's that make up an
invisible HdrFtr for a given DocSectionLayout
fl_ShadowLayout - Collection of fl_BlockLayout's that are copies of
the master HdrFtr that are actually visible and
drawn to the screen.
fl_BlockLayout - Container of text and image runs that make up the
fl_DocListener - Interface between the pieceTable and the Layout
The primary job of the layout classes is to assemble smaller pieces into
larger collections. So fl_BlockLayout assembles runs into lines,
fl_DocSectionLayout assembles lines into columns, fl_HdrFtrSectionLayout
assembles lines into a header/footer etc.
The current class heiracy is:
Within fl_DocSectionLayout is a method called breakSection() and some
associated methods. I think these should be liberated and placed into
seperate classes called fb_BreakSection in analagy with fb_LineBreaker.
The linked list of classes was:
Within each section is a linked list of fl_BlockLayouts.
Each block has is own linked list runs and lines.
So for the next generation code we add cells, tables, footnotes, endnotes
and positioned objects. These must be contained by fl_DocSectionLayout and
they also contain fl_BlockLayouts.
So we need new classes derived from fl_SectionLayout to contain the
fl_BlockLayouts for these new containers.
These are fl_TableSectionLayout, fl_CellSectionLayout,
fl_FootnoteSectionLayout, fl_PositionedSectionLayout. The class heiracy I
The idea of putting fl_BlockLayout and fl_SectionLayout under a new
base class is that methods like the following can be applied to any
Maybe others too.
This allows us to easily generalize the simple linked list of
fl_BlockLayout classes which used to be all a DocSection could hold to
Then each Table holds the following linked list
Each Cell holds:
By placing all these classes under generic heiracy we can apply the same
methods to each.
So a collapse method on a DocSectionLayout is translated down through
all the layout classes under it's linked list.
Now the other thing we do is to generalize fb_BreakSection to assemble not
just lines into columns but any container found in the DocSection into a
column. This code can also be made generic so that for example a cell can
assemble text into itself and we allow containers to be broken.
fl_TableSectionLayout of course needs a method to assemble cells into a
What of fl_DocListener? Well we'll need new piecetable struxes to hold the
properties of the new containers Table,cell,footnote, positionedObject. If
a property of any of these containers change, the contents of the
container are cleared and then recalculated and layed out, the same way we
do things for DocSectionLayouts now.
OK folks, opinions on this? Once again I think it will not be too hard to
refactor the code to allow these generalizations.
This archive was generated by hypermail 2.1.4 : Mon Apr 22 2002 - 11:22:28 EDT