From: msevior_at_physics.unimelb.edu.au
Date: Sun Jan 25 2004 - 07:12:04 EST
OK here's my plan for a Table of Contents.
A Table of contents (TOC) will be a new section class and has it's own
pf_Frag_Strux_Section_TOC and pf_Frag_Strux_EndTOC frags and appropriate
PTX_SectionTOC and PTX_EndTOC ID's.
However my current plan is that these will contain no content at all.
They're just place holders for the attributes/properties we need and to
generate the fl_TOCLayout class in the view classes.
There are fl_TOCLayout and fp_TOCContainer classes. The fl_TOCLayout class
is responsible for fomatting, filling the blocks, looking up the styles etc.
The properties of the TOC section are:
toc-id: A 32 bit unique identifer
toc-source-style-1: The style associated with a level 1 entry in the TOC
toc-source-style-2: The style associated with a level 2 entry in the TOC
toc-source-style-3: The style associated with a level 3 entry in the TOC
toc-source-style-4: The style associated with a level 4 entry in the TOC
toc-dest-style-1: The style blocks at level 1 acquire in the TOC.
toc-dest-style-2: The style blocks at level 2 acquire in the TOC.
toc-dest-style-3: The style blocks at level 3 acquire in the TOC.
toc-dest-style-4: The style blocks at level 4 acquire in the TOC.
So the idea is that although the TOC has no content in the piecetable it
gets filled from the layout level. The content of blocks of style (or
based on a style) that match one of the source styles is copied into the
TOC. Once there all formatting is stripped and instead it acquires the
appropriate toc-dest-style.
This gives us great flexibility about how the TOC will look as we can just
define new styles for each of the toc-source or toc-dest styles to choose
which paragraphs get in the TOC and how they will look once there. Of
course we will define nice defaults so users never have to change these if
they use
Heading 1, Heading 2, Heading 3 styles to identify different headings of the
document.
In addition we can easily have different types of TOC's to list figures,
table or other collections of headings in the document.
The fp_TOCContainer class contains a collection of lines that come form
each of the Blocks. This container is placed in the list of containers in
a docsection
in the smae place that frag is in the PieceTable. This container will be
breakable across pages like Tables.
The blocks in the TOC will not be selectable nor will be able to put the
caret in the TOC because the fp_TOCContainer will not pass mapXYToPosition
down to it's child containters.
fl_BlockLayout will need two extra member boolean variables. m_bIsToc is true
if the fl_BlockLayout is contained by fl_TOCLayout.
The other variable is m_bStyleInTOC is true if the style of the block matches
a toc-source-style of a TOC in the document.
If m_bIsToc is true the properties of the text runs are superseeded by the
toc-dest-style of the TOC.
If m_bStyleInToc is true then changes to contents of the block are mirror
in a block in one or more TOC's.
Pointers to fl_TOCLayout are maintained in a vector in fl_DocLayout. Blocks
determine if m_bStyleInToc is true by calling a new method in fl_DocLayout
from the fl_BlockLayout::_lookupProperties method. The destructor of
fl_BlockLayout should also identify fl_DocLayout if it's in a TOC so the
TOC can remove the Block from it's list.
Finally we need a new field that displays the page number of a particular
block pointer.
There are more details I will work out as I go along. I believe that this
approach will provide us with a state-of-art TOC feature that will update
in real time as you type the document.
If anybody else would like to help out with this, please let me know. I
think we can work on it without stepping on each others toes.
Cheers
Martin
This archive was generated by hypermail 2.1.4 : Sun Jan 25 2004 - 07:13:23 EST