Table of Contents - My Plan.

Date: Sun Jan 25 2004 - 07:12:04 EST

  • Next message: Tomas Frydrych: "commit (HEAD): UUID hashes"

    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

    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.



    This archive was generated by hypermail 2.1.4 : Sun Jan 25 2004 - 07:13:23 EST